Database backups are an essential part of any business continuity and disaster recovery strategy. Using cloud products like Microsoft Business Central includes disaster recovery services such as backups and storage. Here is the overview of backups and restores for Business Central.
Microsoft Dynamics 365 Business Central online service uses Azure SQL Database as the underlying database backup technology for its environments. All databases are protected by automated backups which are continuously created and maintained by the Azure SQL service. The backup retention period for Business Central databases is set to 30 days for both production and sandbox environments. For more information about this backup process, see Automated backups – Azure SQL Database & SQL Managed Instance.
Restoring from a backup is easy. As an administrator, you can restore an existing environment from a time in the past, within the 30-day retention period. An environment can only be restored within the same Business Central version (minor and major).
How often are production databases backed up?
Databases are protected by automatic backups that are kept for 30 days. Administrators of a Business Central tenant can’t directly access or manage these backups because they’re managed automatically by Microsoft. However, administrators can restore their environments to a specific point in time in the past using the Business Central admin center. For more information, see Restoring an environment and Automated backups – Azure SQL Database.
Restoring environments in Business Central admin center
Users who can restore environments
Permission to restore environments is limited to specific types of users: internal and delegated administrators. The following users can restore environments.
- Delegated administrators from reselling partners
- Administrators from the organization that subscribes to Business Central online
Also, these users must have the D365 BACKUP/RESTORE permission set assigned to their user account in the environment they’re trying to export.
For more information about permissions sets and user groups, see Assign Permissions to Users and Groups.
Considerations and limitations when restoring BC
- Environments can only be restored if the customer has a paid Business Central subscription.
- Each environment can be restored up to 10 times in a calendar month.
- It’s not possible to use the Business Central administration center to restore an environment that was previously deleted.
Note: If you end up in the situation where you need to restore a deleted environment, contact Microsoft Support for help. In such cases, Microsoft doesn’t guarantee a restore operation will succeed or all data and extensions will be available in the restored database. So before you decide to delete an environment, it’s important to ensure that the environment is no longer needed.
- An environment can only be restored within the same Azure region and country (Business Central localization) as the original environment.
- A production environment can be restored to either a Production or Sandbox type environment. A sandbox environment can only be restored a Sandbox type environment.
- When restoring a sandbox environment, all development extensions (that is, extensions published directly from Visual Studio Code) won’t be available in the restored environment—even if they were present at the point-in-time you’re restoring to). Additionally, any per-tenant extensions that depend on such development extensions will also not be available.
- Per-tenant extensions you may have uploaded that target the next version of the Business Central won’t be available in the restored environment—even if they were uploaded at the point-in-time you’re restoring to. Per-tenant extensions that were already installed will be available in the restored environment.
- Every AppSource and Business Central app in the restored environment will have the latest available hotfix installed automatically—even if the hotfix was introduced after the point-in-time you’re restoring to.
Backup retention
For all new, restored, and copied databases, Azure SQL Database and Azure SQL Managed Instance retain sufficient backups to allow PITR within the last 7 days by default. With the exception of Hyperscale and Basic tier databases, you can change backup retention period per each active database in the 1-35 day range. As described in Backup storage consumption, backups stored to enable PITR may be older than the retention period. For Azure SQL Managed Instance only, it is possible to set the PITR backup retention rate once a database has been deleted in the 0-35 days range.
If you delete a database, the system keeps backups in the same way it would for an online database with its specific retention period. You cannot change backup retention period for a deleted database.
Important
If you delete a server or a managed instance, all databases on that server or managed instance are also deleted and cannot be recovered. You cannot restore a deleted server or managed instance. But if you had configured long-term retention (LTR) for a database or managed instance, long-term retention backups are not deleted, and can be used to restore databases on a different server or managed instance in the same subscription, to a point in time when a long-term retention backup was taken.
Backup retention for purposes of PITR within the last 1-35 days is sometimes called short-term backup retention. If you need to keep backups for longer than the maximum short-term retention period of 35 days, you can enable Long-term retention.
Long-term retention
For both SQL Database and SQL Managed Instance, you can configure full backup long-term retention (LTR) for up to 10 years in Azure Blob storage. After the LTR policy is configured, full backups are automatically copied to a different storage container weekly. To meet various compliance requirements, you can select different retention periods for weekly, monthly, and/or yearly full backups. Storage consumption depends on the selected frequency and retention periods of LTR backups. You can use the LTR pricing calculator to estimate the cost of LTR storage.
Important
Updating the backup storage redundancy for an existing Azure SQL Database, only applies to the future backups taken for the database. All existing LTR backups for the database will continue to reside in the existing storage blob and new backups will be stored on the requested storage blob type.
As you move your business to the cloud, security and the integrity of your data is always top of mind. Don’t miss out, talk to us today – we offer more than ERP!
