Database point-in-time restore (PITR)
You can use Microsoft Dynamics Lifecycle Services (LCS) to perform the point-in-time restore (PITR) for a Dynamics 365 for Finance and Operations sandbox user acceptance testing (UAT) environment.
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:
- Go to your target sandbox Environment Details page, and select the Maintain > Move database menu option.
- Select the Point-in-time restore option and choose a point-in-time.
- Note the warnings. Review the list of data elements that are not copied over from the previous point-in-time.
- The restore operation will begin immediately.
- After the restore operation is completed, you must Sign off on the operation before you can perform another servicing operation, such as package deployment, database movement, or upgrade.
Restore operation failed
In case of failure, the option to perform a Rollback is available. By clicking the rollback option after the operation has initially failed, your target sandbox environment will be restored to the state it was before the restore began. This will restore the previous database from the deleted databases storage on the Azure SQL Server. This is often required if a customization is present in the target sandbox that cannot complete a database synchronization with the newly-restored data.
To determine the root cause of the failure, download the runbook logs using the available buttons before starting the rollback operation.
Data elements that need attention after restore
When restoring a database from a previous point-in-time, keep in mind that the database is provided as-was. This means that batch jobs and other data elements in the system could be in an in-progress state. These will require manual review.
The System Administrator account in the target environment (UserId of 'Admin') is reset to the value found in the web.config file on the target. This should be the same value as that of the Administrator from Lifecycle Services. To preview which account this will be, go to your target sandbox Environment Details page in LCS. The value of the Environment Administrator field that was selected when the environment was first deployed is updated to be the System Administrator in the transactional database. This also means that the tenant of the environment will be that of the Environment Administrator.
If you have used the Admin User Provisioning Tool on your environment to change the web.config file to a different value, it may not match what is in Lifecycle Services. If you require a different account, you will need to deallocate and delete the target sandbox, and redeploy by selecting another account. After this, you can perform another refresh database action to restore the data.
Steps to complete after a database restore for environments that use Retail functionality
If you copy a database between environments, the copied database won't be fully functional until you run the Environment reprovisioning tool to make sure that all Retail components are up to date.
Follow these steps to run the Environment reprovisioning tool.
- In your project's Asset Library, in the Software deployable packages section, click Import.
- From the list of shared assets, select the Environment Reprovisioning Tool.
- On the Environment details page for your target environment, select Maintain > Apply updates.
- Select the Environment Reprovisioning tool that you uploaded earlier, and then select Apply to apply the package.
- Monitor the progress of the package deployment.
Some environment specific records cannot be moved along with the database from the source to the target environment. The following records are not moved to the target environment:
- Retail Self-Service installers
- Retail Cloud Scale Unit channel database configuration record
Database refresh and Retail Cloud Scale Units
As part of database refresh, scale unit channel database records (in the Channel Database form) cannot be moved across environments since they represent environment specific configuration.
For Retail Cloud Scale Units, you can regenerate the channel database record by issuing a re-deployment of your scale units in LCS. For more information, see Database refresh and Initialize Retail Cloud Scale Unit.
Database refresh and Retail Self-Service installers
Self-service installers are stored in environment specific storages that cannot be moved along with the database.
Installers are uploaded to the environment as part of a deployable package. The application and binary packages provided by Microsoft will contain the Microsoft provided installers. The Retail Deployable package produced by extensions through the Retail SDK will contain the extended installers. To make installer section available after database refresh, please apply the desired deployable package to the environment after database refresh.
Point-in-time restore breaks the chain of available restore points
The restore database process always creates a new database based on a previous point-in-time snapshot. Because of this, the new database does not have any restore history, but does begin to accrue new restore points going forward. This means that after performing point-in-time restore you will not be able to do so again using the same restore date and time.
Going forward, the Lifecycle Services team will work to improve point-in-time restore by leveraging the restore history of deleted databases. This will allow continual restore back to the same point-in-time for scenarios such as destructive testing. This will be fixed in an upcoming release of LCS.
Restore is denied for environments running Platform update 3 or earlier
The restore database process cannot be completed if the environment is running Platform update 3 or earlier. For more information, see the list of currently supported Platform updates.