Create SAP HANA snapshot-based backups

3 minutes

SAP HANA supports storage snapshots (this is restricted to single-container systems). SAP HANA MCS with more than one tenant doesn't support this kind of SAP HANA database snapshot.

The process works as follows:

Prepare for a storage snapshot by initiating the SAP HANA snapshot.
Run the storage snapshot (Azure blob snapshot, for example).
Confirm the SAP HANA snapshot.

The snapshot then also appears in the backup catalog in SAP HANA Studio. On disk, the snapshot shows up in the SAP HANA data directory. It's necessary to ensure that the file system consistency is also guaranteed before running the storage snapshot while SAP HANA is in the snapshot preparation mode.

Once the storage snapshot is done, it's critical to confirm the SAP HANA snapshot. There's a corresponding SQL statement to run: BACKUP DATA CLOSE SNAPSHOT (see BACKUP DATA CLOSE SNAPSHOT Statement (Backup and Recovery)).

Important

Make sure to confirm the HANA snapshot. Due to "Copy-on-Write," SAP HANA might require extra disk space in snapshot-prepare mode, and it's not possible to start new backups until the SAP HANA snapshot is confirmed.

HANA virtual machine backup via Azure Backup service

The backup agent of the Azure Backup service isn't available for Linux virtual machines. Moreover, Linux doesn't have similar functionality as Windows has it with VSS. To make use of Azure backup on the file/directory level, one would need to copy SAP HANA backup files to a Windows virtual machine and then use the backup agent. Otherwise, only a full Linux virtual machine backup is possible via the Azure Backup service.

The Azure Backup service offers an option to back up and restore a virtual machine. There are, however, two important considerations:

For Linux virtual machines, only file-consistent backups are possible, since Linux doesn't have an equivalent platform to VSS.
Applications need to implement their own integrity validation mechanism for the restored data.

Therefore, one has to make sure SAP HANA is in a consistent state on disk when the backup starts. More specifically, it's recommended to confirm or abandon a storage snapshot as soon as possible after it has been created. While the storage snapshot is being prepared or created, the snapshot-relevant data is frozen. While the snapshot-relevant data remains frozen, changes can still be made in the database. Such changes won't cause the frozen snapshot-relevant data to be changed. Instead, the changes are written to positions in the data area that are separate from the storage snapshot. Changes are also written to the log. However, the longer the snapshot-relevant data is kept frozen, the more the data volume can grow.

Azure Backup takes care of the file system consistency via Azure Virtual Machine extensions. These extensions aren't available standalone and work only in combination with Azure Backup service. Nevertheless, it's still a requirement to provide scripts to create and delete an SAP HANA snapshot to guarantee app consistency.

Azure Backup, in this case, has four major phases:

Execute prepare script - script needs to create an SAP HANA snapshot
Take snapshot
Execute post-snapshot script - script needs to delete the SAP HANA snapshot created by the prepare script
Transfer data to vault

For details on where to copy these scripts and details on how Azure Backup works exactly, check the following articles:

Plan your virtual machine backup infrastructure in Azure: An overview of Azure Virtual Machine backup
Application-consistent backup of Azure Linux virtual machines: Application-consistent backup of Azure Linux virtual machines

At the time of authoring, Microsoft hasn't published prepare-scripts and post-snapshot scripts for SAP HANA. You as the customer or system integrator would need to create those scripts and configure the procedure based on the documentation referenced above.

Restore from application consistent backup against a virtual machine

Azure Backup provides the capability to restore Azure Virtual Machines and disks from Azure Virtual Machine backups, also known as recovery points. This section describes how to recover files and folders from an Azure Virtual Machine backup. Restoring files and folders is possible only for Azure Virtual Machines deployed using the Resource Manager model and protected by a Recovery Services vault.

Mount the volume and copy files

Sign in to the Azure portal and in the left pane, select Virtual machines. From the list of virtual machines, select the virtual machine to open that virtual machine's menu.
On the virtual machine's menu, select Backup to open the Backup dashboard.
On the Backup menu, select File Recovery.
From the Select recovery point drop-down menu, select the recovery point that contains the files you want. By default, the latest recovery point is already selected.
To download the software used to copy files from the recovery point, select Download Executable (for Windows Azure Virtual Machine) or Download Script (for Linux Azure Virtual Machine, a python script is generated).
The executable or script is password protected and requires a password. In the File Recovery menu, select the copy button to load the password into memory.
From the download location (usually the Downloads folder), right-select the executable or script and run it with Administrator credentials. When prompted, type the password or paste the password from memory, and press Enter. Once the valid password is entered, the script connects to the recovery point. If you run the script on a computer with restricted access, ensure there's access to:
- download.microsoft.com
- Recovery Service URLs (geo-name refers to the region where the recovery service vault resides)
  - https://pod01-rec2.geo-name.backup.windowsazure.com (For Azure public geos)
  - https://pod01-rec2.geo-name.backup.windowsazure.cn (For Azure China 21Vianet)
  - https://pod01-rec2.geo-name.backup.windowsazure.us (For Azure US Government)
  - https://pod01-rec2.geo-name.backup.windowsazure.de (For Azure Germany)
- outbound port 3260
Identify the mounted volumes:
- Windows: When you run the executable, the operating system mounts the new volumes and assigns drive letters. You can use Windows Explorer or File Explorer to browse those drives. The drive letters assigned to the volumes may not be the same letters as the original virtual machine, however, the volume name is preserved. Browse through all volumes mentioned in the script output until you find your files/folder.
- Linux: In Linux, the volumes of the recovery point are mounted to the folder where the script is run. The attached disks, volumes, and the corresponding mount paths are shown accordingly. These mount paths are visible to users having root level access. Browse through the volumes mentioned in the script output.
Identify and copy files to the local file system
After identifying the files and copying them to a local storage location, remove (or unmount) the extra drives. To unmount the drives, on the File Recovery menu in the Azure portal, select Unmount Disks.

HANA license key and virtual machine restore via Azure Backup service

The Azure Backup service allows creating a new virtual machine during restore. One can choose between creating a virtual machine during restore, restoring the disks, or restoring disk content (as described in the previous section). After restoring the disks, it's still necessary to create a new virtual machine on top of it. Whenever a new virtual machine gets created on Azure the unique VM ID changes.

As the result of the restore via Azure Backup service, Azure Virtual Machine unique ID changes. The SAP hardware key, which is used for SAP licensing, is using this unique VM ID. As a consequence, a new SAP license has to be installed after a virtual machine restore.

SAP HANA virtual machine backup via manual disk snapshot

Instead of using the Azure Backup service, one could configure an individual backup solution by creating blob snapshots of Azure VHDs manually via PowerShell. This offers more flexibility but doesn't resolve the issues described earlier:

You still must make sure that SAP HANA is in a consistent state by creating an SAP HANA snapshot.
The OS disk can't be overwritten even if the virtual machine is deallocated because of an error stating that a lease exists. It only works after deleting the virtual machine, which would lead to a new unique VM ID and the need to install a new SAP license.

It's possible to restore only the data disks of an Azure Virtual Machine (avoiding the problem of getting a new unique VM ID and, therefore, invalidated the SAP license) by using the following procedure: