Azure offers diverse backup capabilities, spanning a wide range of on-premises and cloud-based workloads. These capabilities include a number of options to perform backups of SAP HANA running in Azure virtual machines (VMs). The purpose of this article is to provide an overview of these options.
Traditionally, these options could be grouped into two main categories. The first one relied on Azure Backup while the other comprised third-party Marketplace offerings. Azure NetApp Files, which became generally available at the end of May 2019, could be potentially viewed as third category. While this is an Azure first-party service, delivered and supported by Microsoft, it is based on the NetApp’s ONTAP technology and, unlike other solutions presented here, does not integrate with Azure Backup.
All of the remaining options not only support such integration but also rely, at least to some extent, on the existence of an Azure Recovery Services vault. The vault provides a backup management interface and persistent, long-term storage hosting backup data. The vault also offers several security and resiliency-related features that you can implement in order to further protect your workloads, such as geo-replication, soft-delete, and automatic notifications in case of events indicating potentially unauthorized or unintended destructive activities.
With this short introduction behind us, let’s review six different options to backup SAP HANA running in an Azure VM.
Back up SAP HANA Single Database Container (with HANA 1.x) and Multi-Database Container (with HANA 2.x) databases directly into an Azure Recovery Services vault.
In this case, Azure Backup leverages the SAP proprietary backup API referred to as Backint, which facilitates integration with SAP, allowing direct, streaming backup of SAP HANA database and redo logs into the vault (incidentally, the same mechanism is used by a number of third party backup vendors, such as Commvault). Log backups follow the first full successful database backup, with configurable frequency (down to 15 minutes). This approach not only offers simplicity, but also provides extra benefits derived from the capabilities inherent to Backint, such as checksum-based integrity checks during backups and restores.
Perform a native backup of SAP HANA to a local Azure VM disk and back up the disk’s file system into an Azure Recovery Services vault.
The benefit of this approach is its ability to support practically any SAP HANA installation, or, for that matter, any workload that has the ability to perform native backups. Its primary drawback is the need for an extra step during backup and restore as well as for additional local disk space.
Generate storage snapshots of Azure VM disks hosting the SAP HANA database and back up the snapshots into an Azure Recovery Services vault.
This functionality requires that the disks use the Premium SSD performance tier of Azure Storage and, as the result, is not available with Azure Ultra disks, otherwise fully supported as the alternative SAP HANA block storage option. It is important to point out that, in this case, in order for snapshots to be workload consistent, you have to take some additional steps.
In particular, prior to backup, it is necessary to quiesce database activity and, following the snapshot completion, resume it and delete no longer needed snapshots. Typically, you implement these steps by using pre-snapshot and post-snapshot scripts and incorporate them into an Azure Backup job. It is worth noting that Azure Backup automatically excludes from the scope of the snapshot the disks hosting redo logs with the Write Accelerator feature enabled. The primary benefit of snapshots is their inherent ability to complete backups of large databases in a short amount of time, with a negligible impact on the availability of the SAP HANA databases as well as overall utilization of Azure VM network and storage resources. There is also a corresponding benefit during restores, making this approach well suited for fast database recovery. However, you should keep in mind that snapshots do not include integrity checks that are part of Backint-based backups. In addition, the Azure Storage snapshot feature does not guarantee file system consistency across multiple disks.
Perform a native backup of SAP HANA, generate storage snapshots of Azure VM disks hosting the backup files, and back up the snapshots into an Azure Recovery Services vault.
This approach combines the previous two options, allowing you to take advantage of their respective benefits, including the ability to support practically any SAP HANA installation and a negligible impact on the availability of the SAP HANA databases as well as overall utilization of Azure VM network and storage resources.
Perform a native backup of SAP HANA into Azure NetApp Files (ANF)-based Network File System (NFS) share.
The primary benefit of this approach is its simplicity, since SAP HANA supports direct backups to NFS shares. However, this approach tends to be more expensive compared with others presented here.
Generate storage snapshots of Azure VM-mounted NFSv4 ANF-based volumes hosting the SAP HANA database.
The snapshot functionality is part of the ANF offering and does not depend on or integrate with Azure Backup. This configuration is common when using the scale-out SAP HANA topology with a standby node.
This article provided an overview of backup options for SAP HANA running on Azure VMs. In the upcoming articles, we’ll explore these options in more detail.