Highly-available and resilient systems with disaster recovery capabilities built-in are an essential part of all well-designed enterprise application architectures in the cloud. In these scenarios, data backups also play an equally important role as they help protect against instances of data corruption due to manual or application errors. Data backups also come in handy as an easy option to quickly set up development and testing environments and can even help in DR scenarios should all other methods of data recovery fail. It's thus important that Azure users get familiar with the various Azure backup options.
In this blog we’ll cover the backup options on Azure and how they can ensure redundancy and availability for your database. The different options available for database backups in AWS were covered in the first part of this blog series. In the next part of this series we will also explore the enterprise class data backup and protection features offered in Azure by NetApp’s unified data management solution, Cloud Volumes ONTAP.
Databases form the core of any application architecture and are often in a constant state of change, with transactions happening all the time. It’s not uncommon for a data set to grow to an enormous size, taking up terabytes or even petabytes of data. To back up this important information, customers can opt for either the traditional file-based approach or for snapshot-based backups, which leverage the underlying storage layer for protecting their databases. On Azure, backing up databases is an integral part of Azure data recovery.
Traditional IT organizations moving to the cloud frequently start with hybrid architectures, where their application components co-exist both on-premises and in the cloud. One of the most common hybrid cloud use cases is to leverage the cloud for backup, especially when it comes to large databases.
Backups of on-premises databases are taken using file-based backup methods and backup data is moved to cloud storage for long-term retention. File-based backups are usually full backups which include the data and transaction logs of all transactions since the last successful log backup. If supported by the database platform, differential backups can also be triggered to create a backup of all data since the last successful full or differential backup. The cloud acts as the off-site storage location of the backup copy, and the backup files created locally are copied over to target object of file storage in the cloud once the backup operation is complete.
In hybrid cloud scenarios using Azure, Azure Blob or Azure Files can be used as the target. For example, starting with SQL server 2012 SP1 CU2, the ability to back up to Azure Blob storage is baked into the product out of the box. It should be noted that during a recovery operation, a mechanism should be in place that can securely restore data back to the on-premises server.
Note that Cloud Volumes ONTAP offers block-based snapshots which can also address these requirements, but we’ll cover that in the next article in this series.
For born-in-the-cloud databases, additional capabilities such as snapshots, backup redundancy, and managed database services are available and can be utilized to meet database backup and DR requirements.
SQL databases running in Azure can use either block-based storage (VM disks) or object-based storage when the database files are in Azure Blob storage. Snapshot-based Azure database backup options are available in both scenarios. When using block-based storage for Azure storage backup, snapshots can either be application-consistent or crash-consistent, depending on whether the database is aware of the snapshot being taken or not.
Application-consistent snapshots ensure that the recovery point has all the information required to restore from the backup without any additional fixes. The snapshot is taken in collaboration with the application, in this case the database system, so that any pending I/O transactions are committed to storage before the snapshot is taken.
Crash-consistent snapshots on the other hand are taken without the awareness of the application. In the case of database systems, additional database level recovery processes might be required after restoring from a crash-consistent snapshot. It is a highly error prone approach for database recovery and could lead to corrupted databases.
Azure disks have a built-in snapshot capability which is capable of creating application-consistent and crash-consistent snapshots when used in conjunction with Azure backups. The copy-on-write method used by Azure disk maintains a copy of the disk block as it was when the snapshot was taken. This makes the backup more storage efficient while using LRS (Locally Redundant Storage) for the snapshots.
Azure Cloud Backup service can take application-consistent and crash-consistent snapshots of VMs hosting database services. It helps customers avoid the time otherwise required to invest in scripts that are needed to freeze database systems, flush buffers, etc. before a usable snapshot can be taken.
Azure snapshot can also be used to provision new storage volumes based on snapshots. While this cloning process takes place instantly, the clones are loaded lazily in the background. Users can thus start using these volumes immediately before they are completely restored.
This cloning approach is very beneficial for spinning up dev/test environments in DevOps. However, the clones will still consume large amount of storage as they are complete copies of the data. In the third part of this series we will see how Cloud Volumes ONTAP FlexClone® can help customers optimize their storage footprint while cloning for DevOps, testing, and more.
Azure supports zone-redundant snapshots of Azure managed disks. Note that this is currently limited to full backups, with incremental backups expected to be available in the future. Additional redundancy can be achieved by copying the snapshots to alternate locations using tools such as AzCopy. When an Azure snapshot is taken using the Azure Backup service, the underlying Recovery Services Vault can be configured to use GRS (Geo-Redundant Storage) which replicates the backup to paired regions in a geography.
Azure SQL, the Azure managed database service has automated backup capability baked into it free of charge. The backups are stored in read-access Geo-Redundant storage to ensure data availability in the event of a data center outage. SQL technology is used in the backend for Azure database backups to create full, differential and transactional log backups that helps in point in time restore (PITR).
Data is the lifeblood of any enterprise application and it is important to ensure end to end data protection using reliable data backup mechanisms.
This article explored the different file-based and snapshot-based approaches can be used for Azure database backups. Using Azure snapshots may be better for larger databases, but Azure takes a full copy of the data for each snapshot which is time consuming and adversely affects storage economy.
In the last part of this series we will explore the capabilities of NetApp’s Cloud Volumes ONTAP as a database backup solution and how it can help overcome Azure backup limitations. As an enterprise-grade data management platform, it offers single-pane management of your data with application-consistent snapshots that can be stored across multiple Azure regions. To understand how AWS database backups work, check out the first part of the series.
To get started with managing data backup and archive with Cloud Volumes ONTAP right now, use our Azure calculator to see how much it can help you save on Azure storage.