The Rundown on Backups in Microsoft Dynamics 365 Business Central

Visit Website View Our Posts

Database backups are a key part of any disaster recovery strategy. Microsoft Business Central, a cloud product, includes disaster recovery services like backups and storage.  Below is an 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. These databases are protected by automated backups and these backups are repeatedly created and kept up by the Azure SQL service. The Business Central database’s backup retention period is set to 30 days for sandbox and production environments. For more information about this backup process, please see Automated backups – Azure SQL Database & SQL Managed Instance.

It is simple to restore from a backup.  As an admin, you can restore a previous environment from the past as long as it is within the 30-day retention period. As an additional note, an environment can only be restored within the same Business Central version (minor and major).

How often are production databases backed up?

Automatic backups protect databases that are stored for 30 days. Administrators of a Business Central tenant are unable to directly access or manage these backups because Microsoft controls these backups automatically. However, administrators can restore their environments to an exact point in time using the Business Central admin center. For more information about this backup process, please see Restoring an environment and Automated backups – Azure SQL Database.

Restoring environments in Business Central admin center

Users who can restore environments

Specific types of users and administrators have permission to restore environments: internal and delegated administrators. The following users can restore environments.

  • Designated administrators from reselling partners
  • Administrators from organizations that subscribe to online Business Central

These users and administrators also must have the D365 BACKUP/RESTORE permission assigned to the user account they want to export in the environment.

For more information about permissions sets and user groups, please see Assign Permissions to Users and Groups.

Considerations and limitations when restoring Business Central

  • An environment can solely be restored in the case that a customer has a paid Business Central subscription.
  • An individual environment can only be restored at most 10 times in a month.
  • It is impossible to use the BC administration center to restore an environment from backup that was deleted.

An important note:  In the case that you need to restore a deleted environment, reach out to Microsoft Support for assistance. In this type of situation, Microsoft is unable to guarantee that a restore operation will succeed or that all data and extensions will be accessible in the restored database. As an important reminder, before you decide to delete an environment, ensure that the environment is no longer needed.

  • The environments can solely be restored within the exact same Azure region and country (Business Central localization) as the original environment.
  • Production environments can be restored to either a Production or Sandbox type environment. The sandbox environment can only be restored to a Sandbox type environment.
  • It is important to note that when restoring a sandbox environment, all development extensions, which are extensions that are published directly from Visual Studio Code, will not be available in the restored environment. This is the case even if the extensions were present at the point-in-time you are hoping to restore to. In addition, any per-tenant extensions that depend on these development extensions will also not be available.
  • The per-tenant extensions that were uploaded and target the next version of the Business Central will not be available in the restored environment and this is the case even if they were uploaded at the point-in-time you are restoring to. However, the per-tenant extensions that were already installed will be available in the restored environment.
  • Additionally, every AppSource and Business Central app in the restored environment will have the latest available hotfix installed automatically even in the case that the hotfix was introduced after the point-in-time you are choosing to restore to.

Backup retention

In the case of backup retention, for all new, restored, and copied databases, Azure SQL Database and Azure SQL Managed Instance will manage sufficient backups to allow PITR within the last 7 days by default. This is true with the exception of Hyperscale and Basic tier databases, where you can change the PITR backup retention period per each active database within the 1-35 day range. Additionally, as described in Backup storage consumption, the backups stored that enable PITR can be older than the retention period. However, for Azure SQL Managed Instance only, it is possible to set and change the PITR backup retention rate after a database has been deleted within the 0-35 days range.

The system keeps backups in the same way it would for an online database with its specific retention period. As an important reminder, you are unable to change the backup retention period for a deleted database.


In the case that a server or a managed instance is deleted, all the databases on that server or managed instance will also be deleted and are unable to be recovered because you cannot restore a deleted server or managed instance. If you had configured long-term retention (LTR) for a database or managed instance, the long-term retention backups will not be deleted, and can be used to restore databases on a different server or managed instance the same subscription. The databases can be restored to a point in time when a long-term retention backup was taken.

The backup retention for purposes of PITR within the last 1-35 days is sometimes referred to as short-term backup retention. In the case that 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

You can configure full backup long-term retention (LTR) for up to 10 years in Azure Blob storage for both SQL Database and SQL Managed Instance. After the LTR policy is configured, the full backups are automatically copied to another storage container each week and you are able to select different retention periods for weekly, monthly or yearly full backups in order to meet various requirements. The storage consumption depends on the chosen frequency and the LTR backups’ retention periods. In a similar way, you can use the available tools like the LTR pricing calculator to estimate the cost of LTR storage.


In this situation, updating the backup storage redundancy for an existing Azure SQL Database only applies to the future backups that are taken for the database. This is because the existing LTR backups for the database will continue to remain in the current storage blob and the new backups will be stored on the new requested storage blob. When you move your business to the cloud, the security and the integrity of your data is always a priority. Additionally, so you don’t miss out, you can simply talk to us today – we offer more than ERP!

As you move your business data to the cloud, the security and the integrity of your data is always a priority.  So you don’t miss out, reach out and talk to us today – we offer more than ERP!

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Show Buttons
Hide Buttons