Azure NetApp Files
: Restore Your HANA Database from a Snapshot Backup
Bernd Herth
In our previous blog post, Azure NetApp Files – SAP HANA Backup in Seconds, we demonstrated how to create an application-consistent storage snapshot with the help of a small script using Azure NetApp® Files APIs together with the SAP HANA APIs. This script allows customers to back up an SAP HANA database of any size in a few seconds, compared to hours when using standard file-based backups or streaming technology. In this blog post, we describe how to use this snapshot backup to restore the SAP HANA database.
The SAP HANA restore process
Restoring an SAP HANA Multi Database Container (MDC) database is best explained with a picture of the restore process in our lab setup.
An SAP HANA MDC database can be installed on a single host (scale up) or in a multiple-host setup (scale out). It contains a SYSTEM database and one or more tenant databases. For a full restore and recovery, the SAP HANA database must be stopped. After the file structure has been restored, the SYSTEM database needs to be recovered first, followed by recovery of each existing tenant.
The SAP HANA persistence layer
To understand the different options to restore the SAP HANA persistence layer, we need to look at the file system structure of an SAP HANA database. Our example has a single-host SAP HANA system installed that has one tenant database. At the storage level, each host has a single mount point where an ANF volume for each host is mounted:
,
vm-p01:/hana/data/P01/mnt00001 # df -h .
Filesystem Size Used Avail Use% Mounted on
10.0.1.4:/P01-data-mnt00001 101T 7.8G 100T 1% /hana/data/P01/mnt00001
For each host, a numbered mount point (mnt00001, mnt00002,…) is created in the folder /hana/data/P01, where P01 is the system identifier (SID) of the HANA database. On each mount point, a single ANF volume per host is mounted. Following the NetApp naming convention, the volume name and export path are P01-data-mnt00001, where P01 is the SAP HANA SID and mnt00001 is the first and only mount point of the single-host database.
Inside the mounted volume, the following typical folder structure is present:
vm-p01:/hana/data/P01/mnt00001 # ll -a .
total 20
drwxr-x--- 5 p01adm sapsys 4096 May 8 17:56 .
drwxr-x--- 3 p01adm sapsys 22 Apr 10 12:13 ..
drwxrwxrwx 14 root 4096 Aug 20 15:02 .snapshot
drwxr-x--- 2 p01adm sapsys 4096 Aug 2 05:04 hdb00001
drwxr-x--x 2 p01adm sapsys 4096 Apr 11 08:45 hdb00002.00003
drwxr-x--x 2 p01adm sapsys 4096 Aug 2 05:04 hdb00003.00003
-rw-r--r-- 1 p01adm sapsys 17 Aug 5 15:09 nameserver.lck
The SYSTEM database and each tenant have one or more folders, again following an SAP HANA internal naming and numbering schema. Each of the folders contains a single data file, datavolume_0000.dat, which contains the persistence data of the SAP HANA database:
hdb00002.00003:
total 329088
__DO_NOT_TOUCH_FILES_IN_THIS_DIRECTORY__
datavolume_0000.dat
There is also a file called __DO_NOT_TOUCH_FILES_IN_THIS_DIRECTORY__, indicating that users are not supposed to touch any of the files in this structure.
At the time that a storage-based snapshot backup is initiated, SAP HANA ensures that the data volume is in a consistent state, and it creates an additional file, snapshot_databackup_0_1, in this structure, which is later used to identify the backup in case a SAP HANA database recovery is necessary.
Snapshots are always visible
When using Azure NetApp Files for a SAP HANA database, an additional .snapshot directory is visible at the mount point. Under this directory, Azure NetApp Files makes all created snapshots available, giving customers read-only access to the stored backup data.
vm-p01:/hana/data/P01/mnt00001/.snapshot # ll
total 48
drwxr-x--- 5 p01adm sapsys 4096 May 8 17:56 Offline
drwxr-x--- 5 p01adm sapsys 4096 Apr 11 08:45 TEST001
drwxr-x--- 5 p01adm sapsys 4096 Apr 11 08:45 TESTEBID
drwxr-x--- 5 p01adm sapsys 4096 Apr 11 08:45 TESTID
The folder is named after the snapshot name and contains the complete file structure at the time the snapshot was created:
vm-p01:/hana/data/P01/mnt00001/.snapshot/TESTID # ll *
-rw-r--r-- 1 p01adm sapsys 17 Apr 15 10:23 nameserver.lck
hdb00001:
total 3376564
-rw-r----- 1 p01adm sapsys 0 Apr 11 08:44 __DO_NOT_TOUCH_FILES_IN_THIS_DIRECTORY__
-rw-r----- 1 p01adm sapsys 3690987520 Apr 15 10:23 datavolume_0000.dat
-rw-r----- 1 p01adm sapsys 36 Apr 15 06:51 landscape.id
-rw-r----- 1 p01adm sapsys 155648 Apr 15 10:23 snapshot_databackup_0_1
hdb00002.00003:
total 67996
-rw-r--r-- 1 p01adm sapsys 0 Apr 11 08:45 __DO_NOT_TOUCH_FILES_IN_THIS_DIRECTORY__
-rw-r--r-- 1 p01adm sapsys 335659008 Apr 15 10:23 datavolume_0000.dat
hdb00003.00003:
total 3591184
-rw-r--r-- 1 p01adm sapsys 0 Apr 11 08:45 __DO_NOT_TOUCH_FILES_IN_THIS_DIRECTORY__
-rw-r--r-- 1 p01adm sapsys 3892314112 Apr 15 10:23 datavolume_0000.dat
-rw-r----- 1 p01adm sapsys 155648 Apr 15 10:23 snapshot_databackup_0_1
vm-p01:/hana/data/P01/mnt00001/.snapshot/TESTID #
As shown in the listing for the TESTID snapshot, there are several files named snapshot_databackup_0_1 for each of the databases, indicating that this is a valid application-consistent SAP HANA backup that is also referenced in the SAP HANA backup catalog.
Options to restore
These features of Azure NetApp Files enable three different methods to restore an SAP HANA database.
1. Host copy-based restore
Because all snapshots are available in the .snapshot folder, it is possible to copy the files from the snapshot to the original mount point. This host-based copy may take some time, but it has the advantage of being able to restore and recover a single tenant instead of the whole database, simplifying the recovery process.
2. Create a clone
Azure NetApp Files makes it possible to create a new volume based on an existing snapshot. This process is extremely fast, just a few seconds, benefiting from NetApp FlexClone® technology. Instead of the original volume, the new volume is mounted to start the SAP HANA recovery process. The advantage of this procedure is that it leaves the original volume unchanged, while making it possible to recover the system into a new volume.
3. Volume SnapRestore
At the time of this writing, the Volume SnapRestore® option is not yet available for Azure NetApp Files. Nevertheless, it’s worth explaining. Volume SnapRestore is the fastest method to reset a volume back in time to a snapshot. Customers have been using this proven NetApp technology for many years to restore their SAP systems using NetApp storage in their on-premises data centers. Instead of copying data or creating a new volume, the data in the existing volume is restored.
This video, Snapshot-Based Restore for SAP HANA with Azure NetApp Files, shows the complete restore workflow, including the recovery procedure using SAP HANA Studio. The script we’re using automates a copy on host-based restore.
With Azure NetApp Files, customers can optimize the backup and restore and recovery strategy for their SAP HANA systems in the cloud. In upcoming posts, we will discuss how to use these backups to create additional SAP HANA system clones.
For more information, see the following technical reports and web pages:
Bernd Herth
Bernd Herth architects and defines NetApp's SAP solutions as TME at the SAP Partner Port at SAP headquarters in Walldorf. He has over 25 years of experience in SAP software and in planning and architecting infrastructure solutions for SAP and has held various positions in the SAP ecosystem. Herth has published articles and books focused on SAP technology and virtualization. He holds a masters degree in physics and taught computer science classes as assistant professor.
