Backup and Restore Operations

This topic refers only to Order Management Plus: The conditions and events listed on this page occur during the backup and restore operation.

The following conditions and events occur during OM Plus backup and restore:

• The cluster, including RDS, is shut down during the restore process.

• Periodic backups are automatically made by AWS and are stored on S3. AWS also stores write-ahead logs since the last backup so you can restore to any point between the last backup point and a few minutes before the current time.

• The backup functionality is not exposed to users.

• There is no limit on the file size of the DB backup.

• AWS guarantees the data integrity of the backup.

• The backup includes the product catalog.

• Backups are encrypted.

• The backup fails to restore under the following conditions:

  • Changing the encryption keys during restoration of encryption-enabled backup.

  • Restoring encrypted backup on an environment after disabling the encryption.

  • Restoring a regular non-encrypted backup on the environment after enabling encryption.

  • The encryption key is only established once per database life. This is not the same as a PII encryption key. The database encryption key is set upon database creation.

• You must complete the normal AWS authentication or authorization before performing the restore operation.

• The whole database is restored as opposed to only the product catalog or data.

• The database as a whole is restored to its previous state, including settings configured on other services to access database services, such as login credentials, hostname, etc.

• You can perform the restore operation from the AWS IAM console or the AWS command line.

• AWS Identity and Access Management (IAM)controls who can access backups.

• The administrator cannot decrypt and read information from the backed-up data file, such as for debugging purposes. Encryption is transparent and provided by AWS.

• While the restore operation is in progress, all incoming orders from SFDC are stored in a dedicated Kafka queue for 30 minutes.

• Activated orders and in-progress orders go into an unknown state when:

  • They are part of the DIFF between the backed-up database state and current state after a restoration.

  • Orchestration plans were in progress.

  • In the above case, you need to manually analyze the orders.

• A restore operation automatically restarts services which reload from catalog cache.

• Order Management metadata that existed during the backup but was deleted just before restoration will be restored.

• All the Kubernetes pods are shut down during restoration.

• Any order lost during restoration needs manual triaging. This includes incoming MACD orders where related information from a previous order, such as inventory items or the order object, is missing from PSQL after the restore.

• If a new set of Order Management orchestration queues are restored, the dynamic creation, deletion, or allocation of worker pods happens automatically after the database is restored.

• AWS prevents users from restoring a corrupted backup file by mistake.

You will see a message on your Salesforce org notifying you when the cluster is down during a backup and restore process.