Microsoft’s business continuity services are primarily designed to enable businesses to continue operation in the face of disruption to the Azure computing infrastructure. Following the shared responsibility model, SQL Managed Instance will handle most disruptive events that impact availability and security of the cloud to keep applications and business processes running. Their high availability architecture guarantees automatic recovery from these failures with up to 99.995% availability SLA.
However, Microsoft acknowledges there are some disruptive events that impact data availability and security in the cloud and cannot be handled automatically:
To help their customers recover from these types of incidents, Microsoft provides customers with the ability to restore their full database. Let's look at what that process entails.
When a Dynamics 365 SQL Managed Instance database is deleted or corrupted, it can be replaced with a previous version that was backed up at a specific point in time in the past and retained within the retention period using Azure Portal, Azure PowerShell, or REST API. Administrators have four recovery options:
If specific data needs to be restored to recover from a user or application error, administrators need to write and execute a data recovery script that extracts data from the restored database and applies it to the original database. Microsoft cautions the operation may take a long time to complete.
If you are a Dynamics 365 customer and are wondering if the process above meet your needs, here are two important questions to ask yourself:
Is restoring to a production environment possible?
Microsoft is committed to preventing accidental overwrites, and so are conscious about not allowing users to directly restore to a production environment. Some thought has been put into designing the processes this way so that customer data can be better protected. In order to restore to a production environment, users must first switch to a sandbox environment. To learn more about changing your environment type, check out this article.
Users ought to consider their industry’s and/or internal corporate Recovery Point Objective’s (RPOs) reflecting their org’s retention period requirements. RPO shows how far back you can go to retrieve the lost or corrupted data. Production environments have an RPO of 28 days, while sandbox environments have an RPO of seven days. It’s important to be mindful of this, since Microsoft requires customers to switch to a sandbox environment before restoring to their production environment. This renders restore jobs to a seven day RPO–which can be a make or break detail for many organizations.
Can backups be extended to meet retention needs beyond the standard number of days?
Many of our customers ask if the native Microsoft process features a way to extend manual/on-demand backups. For now the answer remains no– and this is also the case for system backups. Those seeking longer retention periods will have to copy their environments to an additional environment, and refrain from making modifications to this new environment.
Most companies can’t afford to play with retention periods as the cost of being out of compliance is too great. In highly regulated industries like Healthcare and Financial Services especially, regulators can impose hefty fines when industry led retention periods fail to be met.
At OwnBackup, we help you keep your data safe and uphold your part of the shared responsibility model. Our market-leading backup and recovery solution, OwnBackup Recover, is currently available for both Microsoft Power Platform (on the Dataverse) and Dynamics 365 customers.
Contact us to learn more about protecting your SaaS data or schedule a customized 1:1 demo today.