Using recovery plans allows you to have far greater control over what is failed over and when. Using this mechanism, you can have more direct control over the timing of failovers for individual services.
Typically, you would group applications into a recovery plan; for example, if you have a web application consisting of a VM frontend and SQL backend, you will group the frontend and SQL server into a recovery plan to ensure they always fail over together.
Next, you can define the order of failover for individual services within that plan. Again, with the web application and SQL server example, you would want to ensure that the SQL server is moved first, followed by the frontend application. The following screenshot shows an example recovery plan in the Azure portal:
Figure 16.3 – Recovery plan example
Grouping services into plans also allows you to manage DR scenarios from the point of view of individual criticality. If you have many different systems, chances are some will be more important than others, or at least need to be brought online quicker. By grouping systems, you can bring each one online in a specific order, and thus prioritize critical systems.
Azure Backup and Azure Site Recovery provide scalable solutions for a wide variety of business requirements; however, they are predominantly designed for Infrastructure as a Service (IaaS) workloads such as VMs and file shares.
Note
For a complete walkthrough of using Azure Recovery Service vaults, see Implementing Microsoft Azure Architect Technologies: AZ-303 Exam Prep and Beyond: A guide to preparing for the AZ-303 Microsoft Azure Architect Technologies certification exam by Packt Publishing.
Many Platform as a Service (PaaS) services, such as Azure SQL and Cosmos DB, also provide backup services, but these are managed within the service itself, as we shall investigate next.
Planning for database backups
In the previous section, we looked at using Azure Backup to create backup and restore policies for VMs, including SQL on VMs.
One of the core offerings of Azure is Azure SQL, a managed database offering with complete flexibility and scalability. However, the Azure Backup solution we looked at for VMs and SQL on VMs is not the same backup solution we use for Azure SQL Database or Azure SQL Managed Instance.
Understanding Azure SQL backups
As managed services, backups are part of the platform, and by default, databases have full backups taken every week, differential backups every 12-24 hours, and transaction log backups every 5-10 minutes. Backups are also retained for 7 days – this means that as soon as you create an Azure SQL database or Azure SQL managed instance, your data is protected so that you can restore data from any point up to 7 days with recovery points every 5-10 minutes.
Backups, by default, are also geo-redundant. This allows you to restore a database to your primary region’s paired region for the same timeframe, thus protecting you against regional outages. Backups also cover you against database deletion, so even if you accidentally delete a database, you can still restore it within the configured retention period.
For some organizations, 7 days retention may not be suitable – some solutions may need to keep longer-term copies for historical or compliance reasons. For this reason, you can increase the retention periods, and how long you need to keep databases for will determine whether you will use Point-in-Time-Restore (PITR) or Long-Term Retention (LTR).
PITR is the standard backups that are taken as part of normal operational processes and can be configured to be retained for up to 35 days.
If you need longer-term backups, you can optionally configure LTR to separate store weekly, monthly, or yearly backups. Each type of backup is stored separately in blob storage, and each type can have its own retention. For example, you could keep weekly backups for 4 weeks, monthly backups for 12 months, and yearly backups for up to 10 years.
The following screenshot shows an example of the preceding retention configuration:
Figure 16.4 – Example SQL database retention configuration
Backup retention policies are configured on SQL Server in the Backups view, and individual policies are configured for each database. If a database is deleted it can therefore be restored from the Backups or Deleted databases view of SQL Server as the database will no longer appear in the normal SQL Databases view in the Azure portal.
Azure’s other core database offering, Cosmos DB, has similar options for backups, but as you would expect, is slightly different.
Leave a Reply