SAP HANA backup based on storage snapshots

Introduction

This is part of a three-part series of related articles on SAP HANA backup. Backup guide for SAP HANA on Azure Virtual Machines provides an overview and information on getting started, and SAP HANA Azure Backup on file level covers the file-based backup option.

When using a VM backup feature for a single-instance all-in-one demo system, one should consider doing a VM backup instead of managing HANA backups at the OS level. An alternative is to take Azure blob snapshots to create copies of individual virtual disks, which are attached to a virtual machine, and keep the HANA data files. But a critical point is app consistency when creating a VM backup or disk snapshot while the system is up and running. See SAP HANA data consistency when taking storage snapshots in the related article Backup guide for SAP HANA on Azure Virtual Machines. SAP HANA has a feature that supports these kinds of storage snapshots.

SAP HANA snapshots

There is a feature in SAP HANA that supports taking a storage snapshot. However, as of December 2016, there is a restriction to single-container systems. Multitenant container configurations do not support this kind of database snapshot (see Create a Storage Snapshot (SAP HANA Studio)).

It 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

This screenshot shows that an SAP HANA data snapshot can be created via a SQL statement

This screenshot shows that an SAP HANA data snapshot can be created via a SQL statement.

The snapshot then also appears in the backup catalog in SAP HANA Studio

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

On disk, the snapshot shows up in the SAP HANA data directory.

One has to ensure that the file system consistency is also guaranteed before running the storage snapshot while SAP HANA is in the snapshot preparation mode. See SAP HANA data consistency when taking storage snapshots in the related article Backup guide for SAP HANA on Azure Virtual Machines.

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

Important

Confirm the HANA snapshot. Due to "Copy-on-Write," SAP HANA might require additional disk space in snapshot-prepare mode, and it is not possible to start new backups until the SAP HANA snapshot is confirmed.

HANA VM backup via Azure Backup service

As of December 2016, the backup agent of the Azure Backup service is not available for Linux VMs. To make use of Azure backup on the file/directory level, one would copy SAP HANA backup files to a Windows VM and then use the backup agent. Otherwise, only a full Linux VM backup is possible via the Azure Backup service. See Overview of the features in Azure Backup to find out more.

The Azure Backup service offers an option to back up and restore a VM. More information about this service and how it works can be found in the article Plan your VM backup infrastructure in Azure.

There are two important considerations according to that article:

"For Linux virtual machines, only file-consistent backups are possible, since Linux does not have an equivalent platform to VSS."

"Applications need to implement their own "fix-up" mechanism on the restored data."

Therefore, one has to make sure SAP HANA is in a consistent state on disk when the backup starts. See SAP HANA snapshots described earlier in the document. But there is a potential issue when SAP HANA stays in this snapshot preparation mode. See Create a Storage Snapshot (SAP HANA Studio) for more information.

That article states:

"It is strongly 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 will not 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 VM extensions. These extensions are not available standalone, and work only in combination with Azure Backup service. Nevertheless, it is still a requirement to manage an SAP HANA snapshot to guarantee app consistency.

Azure Backup has two major phases:

  • Take Snapshot
  • Transfer data to vault

So one could confirm the SAP HANA snapshot once the Azure Backup service phase of taking a snapshot is completed. It might take several minutes to see in the Azure portal.

This figure shows part of the backup job list of an Azure Backup service

This figure shows part of the backup job list of an Azure Backup service, which was used to back up the HANA test VM.

To show the job details, click the backup job in the Azure portal

To show the job details, click the backup job in the Azure portal. Here, one can see the two phases. It might take a few minutes until it shows the snapshot phase as completed. Most of the time is spent in the data transfer phase.

HANA VM backup automation via Azure Backup service

One could manually confirm the SAP HANA snapshot once the Azure Backup snapshot phase is completed, as described earlier, but it is helpful to consider automation because an admin might not monitor the backup job list in the Azure portal.

Here is an explanation how it could be accomplished via Azure PowerShell cmdlets.

An Azure Backup service was created with the name hana-backup-vault

An Azure Backup service was created with the name "hana-backup-vault." The PS command Get-AzureRmRecoveryServicesVault -Name hana-backup-vault retrieves the corresponding object. This object is then used to set the backup context as seen on the next figure.

One can check for the backup job currently in progress

After setting the correct context, one can check for the backup job currently in progress, and then look for its job details. The subtask list shows if the snapshot phase of the Azure backup job is already completed:

$ars = Get-AzureRmRecoveryServicesVault -Name hana-backup-vault
Set-AzureRmRecoveryServicesVaultContext -Vault $ars
$jid = Get-AzureRmRecoveryServicesBackupJob -Status InProgress | select -ExpandProperty jobid
Get-AzureRmRecoveryServicesBackupJobDetails -Jobid $jid | select -ExpandProperty subtasks

Poll the value in a loop until it turns to Completed

Once the job details are stored in a variable, it is simply PS syntax to get to the first array entry and retrieve the status value. To complete the automation script, poll the value in a loop until it turns to "Completed."

$st = Get-AzureRmRecoveryServicesBackupJobDetails -Jobid $jid | select -ExpandProperty subtasks
$st[0] | select -ExpandProperty status

HANA license key and VM restore via Azure Backup service

The Azure Backup service is designed to create a new VM during restore. There is no plan right now to do an "in-place" restore of an existing Azure VM.

This figure shows the restore option of the Azure service in the Azure portal

This figure shows the restore option of the Azure service in the Azure portal. One can choose between creating a VM during restore or restoring the disks. After restoring the disks, it is still necessary to create a new VM on top of it. Whenever a new VM gets created on Azure the unique VM ID changes (see Accessing and Using Azure VM Unique ID).

This figure shows the Azure VM unique ID before and after the restore via Azure Backup service

This figure shows the Azure VM unique ID before and after the restore via Azure Backup service. 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 VM restore.

A new Azure Backup feature was presented in preview mode during the creation of this backup guide. It allows a file level restore based on the VM snapshot that was taken for the VM backup. This avoids the need to deploy a new VM, and therefore the unique VM ID stays the same and no new SAP HANA license key is required. More documentation on this feature will be provided after it is fully tested.

Azure Backup will eventually allow backup of individual Azure virtual disks, plus files and directories from inside the VM. A major advantage of Azure Backup is its management of all the backups, saving the customer from having to do it. If a restore becomes necessary, Azure Backup will select the correct backup to use.

SAP HANA VM 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. See Using blob snapshots with PowerShell for a description of the steps.

It provides more flexibility but does not resolve the issues explained earlier in this document:

  • One still must make sure that SAP HANA is in a consistent state
  • The OS disk cannot be overwritten even if the VM is deallocated because of an error stating that a lease exists. It only works after deleting the VM, which would lead to a new unique VM ID and the need to install a new SAP license.

It is possible to restore only the data disks of an Azure VM

It is possible to restore only the data disks of an Azure VM, avoiding the problem of getting a new unique VM ID and, therefore, invalidated the SAP license:

  • For the test, two Azure data disks were attached to a VM and software RAID was defined on top of them
  • It was confirmed that SAP HANA was in a consistent state by SAP HANA snapshot feature
  • File system freeze (see SAP HANA data consistency when taking storage snapshots in the related article Backup guide for SAP HANA on Azure Virtual Machines)
  • Blob snapshots were taken from both data disks
  • File system unfreeze
  • SAP HANA snapshot confirmation
  • To restore the data disks, the VM was shut down and both disks detached
  • After detaching the disks, they were overwritten with the former blob snapshots
  • Then the restored virtual disks were attached again to the VM
  • After starting the VM, everything on the software RAID worked fine and was set back to the blob snapshot time
  • HANA was set back to the HANA snapshot

If it was possible to shut down SAP HANA before the blob snapshots, the procedure would be less complex. In that case, one could skip the HANA snapshot and, if nothing else is going on in the system, also skip the file system freeze. Added complexity comes into the picture when it is necessary to do snapshots while everything is online. See SAP HANA data consistency when taking storage snapshots in the related article Backup guide for SAP HANA on Azure Virtual Machines.

Next steps