Redigera

Dela via

Database point-in-time restore (PITR)

  • Artikel

You can use Microsoft Dynamics Lifecycle Services (LCS) to perform the point-in-time restore (PITR) for a sandbox user acceptance testing (UAT) environment or a production environment (live). Microsoft maintains automated backups of the business and financial reporting databases for 28 days for production environments and 7 days for sandbox environments.

Self-service point-in-time restore

To restore the database of a standard user acceptance test (UAT) environment to a previous point-in-time, follow the steps outlined below:

  1. Go to your target sandbox Environment Details page, and select the Maintain > Move database menu option.
  2. Select the Point-in-time restore option and choose a point-in-time.
  3. Note the warnings. Review the list of data elements that are not copied over from the previous point-in-time.
  4. The restore operation will begin immediately.

Important

Restoring the database in production to a previous point-in-time is not a common lifecycle operation and could result in the following issues:

  • Large downtime for the production environment. Point-in-time restore (PITR) may take multiple hours, depending on the database size.
  • SQL data loss. SQL data loss would depend on how far back the PITR request is made.
  • Breaking of the SQL database chain of available restore points.

To restore the database of a production environment to a previous point-in-time, follow the steps outlined below:

  1. Go to your target production Environment Details page, and select the Maintain > Move database menu option.
  2. Select the Point-in-time restore option and choose a point-in-time.
  3. Note the warnings. Review the list of data elements that are not copied over from the previous point-in-time.
  4. The restore operation will begin immediately.

Applicable scenario for production restore

Restoring the database in production to a previous point-in-time isn't a common lifecycle operation. However, it might be required to recover your production environment if it has undergone significant data corruption. Keep in mind that the operation could have a large downtime and SQL data loss up to the point of time of the request.

Restore operation failed

In the event of failure, the restore operation automatically rolls back. If you select the rollback option after the operation originally fails, your target sandbox environment is restored to the state that it was in before the restore began. A rollback is often required if a customization that is present in the target sandbox environment can't complete a database synchronization with the newly restored data.

To determine the root cause of the failure, use the Environment change history page to download the logs for the failed operation.

Data elements that need attention after restore

When you restore a database from a previous point in time, keep in mind that the database is provided "as was." For example, batch jobs and other data elements in the system can be in an in-progress state. These elements will require manual review.

Note

Restore does affect the tables that store references to files stored in Azure blob storage (like document attachments and custom Microsoft Office templates). However, as Azure blob storage itself isn't affected by this process, any files added after the restore point will continue to exist in Azure blob storage but will not be reflected in the database.

Environment administrator

The system administrator account in the target environment (that is, the account that has a UserId value of Admin) is reset to the value that is found in the web.config file in the target environment. This value should match the value of the administrator account in LCS. To preview which account will be used, go to the Environment Details page for your target sandbox environment in LCS. The value that was selected in the Environment Administrator field when the environment was first deployed is updated to the system administrator in the transactional database. The tenant of the environment will be the tenant of the environment administrator.

If you've used the Admin User Provisioning Tool in your environment to change the value in the web.config file, the value might not match the value in LCS. If you require a different account, you must deallocate and delete the target sandbox environment, and then redeploy it by selecting another account. You can then do another refresh database action to restore the data.

Steps to complete after a database restore for environments that use Commerce functionality

Important

When a Commerce headquarters database (previously called AOS database) is migrated, the associated Commerce Scale Units (CSUs) are not moved. In several cases, depending on the features that are in use, a CSU redeployment may be required. Redeployment must then be followed by a full synchronization of data to the CSU. In extreme scenarios where data discrepancies still exist, the final action is to delete the CSU, deploy a fresh CSU to replace it, and then perform a full synchronization of data to the new CSU.

Some environment-specific records are not included in automated database movement operations and require additional steps. These include the following:

  • Commerce self-service installer references.
  • Commerce Scale Unit channel database configuration records.

If you copy a database between environments, Commerce capabilities in the destination environment won't be fully functional until you perform the following additional steps.

Initialize Commerce Scale Units

If you're moving a database to a sandbox user acceptance testing (UAT) or production environment, you must Initialize Commerce Scale Unit after the database movement operation is complete. The Commerce Scale Unit's association from the source environment won't copy over to the destination environment.

Synchronize Commerce self-service installers

To be able to access Commerce self-service installers in headquarters, you must Synchronize self-service installers after the database movement operation is complete.

Important

The environment reprovisioning step has now been fully automated as part of database movement operations, and no longer needs to be run manually. The environment reprovisioning tool is still available in the asset library, but is only required for restoring a database to a development environment running Commerce version 10.0.37 or earlier. For development environments running Commerce version 10.0.38 and later, the environment reprovisioning tool doesn't apply because these environments use a sealed CSU.

To run the environment reprovisioning tool on the destination environment, run the following steps:

  1. In your project's Asset Library, in the Software deployable packages section, select Import.
  2. From the list of shared assets, select the Environment Reprovisioning Tool.
  3. On the Environment details page for your destination environment, select Maintain > Apply updates.
  4. Select the Environment Reprovisioning tool that you uploaded earlier, and then select Apply to apply the package.
  5. Monitor the progress of the package deployment.

For more information about how to apply a deployable package, see Create deployable packages of models. For more information about how to manually apply a deployable package, see Install deployable packages from the command line.

Reactivate POS devices

If you use point of sale (POS) devices, you must activate the POS devices again after you import a database. Previously activated devices in the destination environment will no longer function. For more information, see Point of sale device activation.

Known issues

Breaking the chain of available restore points

Several frequently used actions create a new database that won't have the same restore point history as the previously used database. These actions include point-in-time restores, database refreshes, database imports, and point-in-time restores from the production environment to the sandbox environment. In addition, if a software deployable package that you apply to your environment fails during update of the database, and you use the rollback functionality in LCS, the rollback functionality does a point-in-time restore of the database, and that restore also creates a new database.

Although the new database doesn't have any restore point history, it does begin to accrue new restore points from that time onward. After you perform any of the previously mentioned actions, you can't perform it again by using the same restore date and time.

Restore is denied for environments that run Platform update 20 or earlier

The restore database process can't be completed if the environment is running Platform update 20 or earlier. For more information, see the list of currently supported Platform updates in the Software lifecycle policy and cloud releases.