This document provides guidance on using SAP HANA Studio to recover SAP HANA on Azure NetApp Files. This guide has step-by-step screenshots to follow to understand the three primary methods of recovering SAP HANA using HANA Studio from a snapshot taken using the Microsoft provided AzAcSnap tool.

The screenshots in this document are from SAP HANA Studio session accessing SAP HANA 2.0SPS04.

Disclaimer: This guide and the associated screenshots are taken from an SAP HANA v2.0 system recovery as set up in the Microsoft test environment for SAP HANA on an Azure Virtual Machine with Azure NetApp Files storage. Anyone following this guide is responsible for ensuring the recovery process works in their own environment as expected.

Assumptions

The administrator following this guide has experience with SAP HANA and HANA Studio because not all details are provided as screenshots to follow (e.g. logging in to HANA Studio, etc.).

The administrator is familiar with SAP HANA backup processes, including the Backup Catalog and Storage Snapshots.

The administrator has the appropriate permissions at a Linux shell to copy files as the <sid>adm user into the SAP HANA Data Area.

Terms and Definitions

Terms used in this documentation:

SID: A System Identifier for SAP HANA installation, typically 3 characters long.
ANF: Azure NetApp Files.
VM: Virtual Machine.

System status

The system layout used for this documentation has a “primary” SID (PR1) and another second tenant (PR2).

The second tenant (PR2) was created using the SQL commands:

CREATE DATABASE PR2 SYSTEM USER PASSWORD <SomePassword>

The primary data area is under “/hana/data/PR1/mnt00001”. Further explanation of the SAP HANA persistent data storage area is in the Appendix.

Recover the database to its most recent state

In this case the goal is to restore the complete system (SYSTEMDB, PR1, PR2) from a snapshot to the most recent database state, including any log replay.

First step is to stop the database

You may need to provide the <sid>adm user and password to shut-down the database.

When this is finished, the Processes tab should display as follows:

Start the recovery process from the menu.

Note, the recovery wizard can take several seconds to launch (see the following status):

Choose the recovery type, in this case “Recover the database to its most recent state”

Choose the location of the backup catalog, which is needed for recovery.

The backup catalog will be fetched to display the appropriate backup to recover from (this can take a minute or two to load

The first time the backup catalog is refreshed, its likely no suitable snapshot will be found to restore from. This is because the administrator will need to copy/restore the files from the snapshot into the data area.

Restore the snapshot files for recovery using either option (a) Revert Volume from Snapshot or option (b) Copy files. Option (a) is faster.
1. Revert Volume from Snapshot – this will roll a Volume back to a prior state and any data or snapshots added to the Volume after the Snapshot used to revert to are lost. At this time Reverting a Volume can only be done using the Azure Portal.
  
  ! Make sure SAP HANA is not running before reverting any volumes.
  
  If dealing with multiple Volumes make a note of the snapshot name you are reverting to as they all must have the same snapshot name.
  
  After completing the Volume Revert it’s a good idea to remount the volumes:
```
# mount -o remount /hana/data/PR1/
```
2. Copy files - In this example, the files are copied from the “hidden” snapshot location in the filesystem.
```
# su - pr1adm
> cp -pr /hana/data/PR1/mnt00001/.snapshot/PR1_hourly__2022-03-31T220003-7196432Z/* /hana/data/PR1/mnt00001/.
```
3. Single file snapshot restore
  Alternatively Azure NetApp Files single file snapshot restore feature can be used to restore files without the need to copy any of them across the network.

When the copy is complete, refresh the view of the backup catalog to ensure the snapshot we are restoring from is listed.

Now select the available SNAPSHOT shown in green to recover from.

Choose the location of the Log Backups.
Check any appropriate “Other Settings”, the following screen is the defaults

On the summary page, review any final details and press Finish to restore the system database.

While the recovery is in progress, the following screen is displayed:

When the recovery has finished a Recovery Execution Summary provides details of the recovery. The following screen shows a completed recovery of the SYSTEMDB.

! Note the message stating “recovering the system database from a storage snapshot invalidates all the tenant databases”. Tenant databases must now be recovered.

Start the recovery of the Tenant database

Choose the Tenant to recover from.

Choose to recover the tenant database to its most recent state (same as for the system database).

Provide the location of the Backup Catalog (same as for the system database)

Allow the tenant database to be stopped for recovery.
Wait for the Backup Catalog to be refreshed and displayed

When recovering the tenant database there should already be a valid snapshot to recover from (unlike the system database where we needed to restore the snapshot files into the data area and refresh the view). Select this snapshot and click next.

Specify any locations for log backups to include in the recovery process.

Check any appropriate “Other Settings”, the following screen is the defaults
On the summary page, review any final details and press Finish to restore the tenant database. Select Finish to proceed with the recovery.
The recovery process can take a few minutes, depending on database size and log files to process.

When the recovery has finished a Recovery Execution Summary provides details of the recovery. The following screen shows a completed recovery of the TENANT DB.

The following screenshot shows the database after recovery with some services running.

Note, there is no process for PR2 running, this tenant still needs to be recovered

Repeat the steps 14-25 to recover any other tenants.

In our example, after recovering tenant PR2, the process list looks like the following:

A process listing can also be retrieved form the command line when logged in as the <sid>adm user.

> /usr/sap/hostctrl/exe/sapcontrol -nr 00 -function GetProcessList
01.04.2022 01:19:55
GetProcessList
OK
name, description, dispstatus, textstatus, starttime, elapsedtime, pid
hdbdaemon, HDB Daemon, GREEN, Running, 2022 04 01 01:06:14, 0:13:41, 713
hdbcompileserver, HDB Compileserver, GREEN, Running, 2022 04 01 01:07:04, 0:12:51, 1653
hdbindexserver, HDB Indexserver-PR1, GREEN, Running, 2022 04 01 01:14:54, 0:05:01, 3929
hdbindexserver, HDB Indexserver-PR2, GREEN, Running, 2022 04 01 01:17:39, 0:02:16, 5302
hdbnameserver, HDB Nameserver, GREEN, Running, 2022 04 01 01:06:14, 0:13:41, 731
hdbpreprocessor, HDB Preprocessor, GREEN, Running, 2022 04 01 01:07:04, 0:12:51, 1656
hdbwebdispatcher, HDB Web Dispatcher, GREEN, Running, 2022 04 01 01:07:05, 0:12:50, 1702
hdbxsengine, HDB XSEngine-PR1, GREEN, Running, 2022 04 01 01:15:11, 0:04:44, 4266

Recover the database to the following point in time

This process allows recovery of the database to a specific point in time, perhaps just prior to an invalid transaction.

First step is to stop the database

When this is finished, the Processes tab should display as follows:
Start the recovery process from the menu.

Note, the recovery wizard can take several seconds to launch (see the following status)
Choose the recovery type, in this case “Recover the database to the following point in time”, in this example the time stamp chosen is 01-April-2022 10:30:00 (in 24 hour GMT+13)

! Note the time used is based on UTC/GMT.
Confirm the recovery to continue, noting the potential for lost data.
Choose the location of the backup catalog, which is needed for recovery.
The backup catalog will be fetched to display the appropriate backup to recover from (this can take a minute or two to load)
The first time the backup catalog is refreshed, its likely no suitable snapshot will be found to restore from. This is because the administrator will need to copy/restore the files from the snapshot into the data area.
Restore the snapshot files for recovery using either option (a) Revert Volume from Snapshot or option (b) Copy files. Option (a) is faster.
1. Revert Volume from Snapshot – this will roll a Volume back to a prior state and any data or snapshots added to the Volume after the Snapshot used to revert to are lost.
  At this time Reverting a Volume can only be done using the Azure Portal.
  
  ! Make sure SAP HANA is not running before reverting any volumes.
  
  If dealing with multiple Volumes make a note of the snapshot name you are reverting to as they all must have the same snapshot name.
  
  We are reverting from the latest snapshot taken BEFORE our target recovery time.
2. Copy files - In this example, the files are copied from the “hidden” snapshot location in the filesystem.
```
# su - pr1adm
> cp -pr /hana/data/PR1/mnt00001/.snapshot/PR1_hourly__2022-03-31T210004-1084693Z/* /hana/data/PR1/mnt00001/.
```
3. Single file snapshot restore
  Alternatively Azure NetApp Files single file snapshot restore feature can be used to restore files without the need to copy any of them across the network.
When the copy is complete, refresh the view of the backup catalog to ensure the snapshot we are restoring from is listed.
Now select the available SNAPSHOT shown in green to recover from.
Choose the location of the Log Backups.
Check any appropriate “Other Settings”, the following screen is the defaults
On the summary page, review any final details and press Finish to restore the system database.
When the recovery has finished a Recovery Execution Summary provides details of the recovery. The following screen shows a completed recovery of the SYSTEMDB.

! Note the message stating “recovering the system database from a storage snapshot invalidates all the tenant databases”. Tenant databases must now be recovered.
Start the recovery of the Tenant database
Choose the Tenant to recover from. At the time of writing, only a single tenant database is supported by SAP to recover from.
Choose to recover the tenant database to the following point in time (same as for the system database).
Provide the location of the Backup Catalog (same as for the system database)
Allow the tenant database to be stopped for recovery.
Wait for the Backup Catalog to be refreshed and displayed
When recovering the tenant database there should already be a valid snapshot to recover from (unlike the system database where we needed to restore the snapshot files into the data area and refresh the view). Select this snapshot and click next.
Specify any locations for log backups to include in the recovery process.
Check any appropriate “Other Settings”, the following screen is the defaults.
On the summary page, review any final details and press Finish to restore the tenant database. Select Finish to proceed with the recovery.
The recovery process can take a few minutes, depending on database size and log files to process.
When the recovery has finished a Recovery Execution Summary provides details of the recovery. The following screen shows a completed recovery of the TENANT DB.
The following screenshot shows the database after recovery with some services running.

Note, there is no process for PR2 running, this tenant still needs to be recovered

Repeat the steps 14-25 to recover any other tenants.

In our example, after recovering tenant PR2, the process list looks like the following:

A process listing can also be retrieved form the command line when logged in as the <sid>adm user.

> /usr/sap/hostctrl/exe/sapcontrol -nr 00 -function GetProcessList
01.04.2022 01:19:55
GetProcessList
OK
name, description, dispstatus, textstatus, starttime, elapsedtime, pid
hdbdaemon, HDB Daemon, GREEN, Running, 2022 04 01 01:06:14, 0:13:41, 713
hdbcompileserver, HDB Compileserver, GREEN, Running, 2022 04 01 01:07:04, 0:12:51, 1653
hdbindexserver, HDB Indexserver-PR1, GREEN, Running, 2022 04 01 01:14:54, 0:05:01, 3929
hdbindexserver, HDB Indexserver-PR2, GREEN, Running, 2022 04 01 01:17:39, 0:02:16, 5302
hdbnameserver, HDB Nameserver, GREEN, Running, 2022 04 01 01:06:14, 0:13:41, 731
hdbpreprocessor, HDB Preprocessor, GREEN, Running, 2022 04 01 01:07:04, 0:12:51, 1656
hdbwebdispatcher, HDB Web Dispatcher, GREEN, Running, 2022 04 01 01:07:05, 0:12:50, 1702
hdbxsengine, HDB XSEngine-PR1, GREEN, Running, 2022 04 01 01:15:11, 0:04:44, 4266

Recover the database to a specific data (snapshot) backup

This process recovers the database to a specific snapshot only (i.e. no log replay).

First step is to stop the database

When this is finished, the Processes tab should display as follows:
Start the recovery process from the menu.

Note, the recovery wizard can take several seconds to launch (see the following status)
Choose the recovery type, in this case “Recover the database to a specific data backup”.
Confirm the recovery to continue, noting the potential for lost data.
As there will be no log replay, continue to “Recover without the backup catalog”.
Specify the Backup to Recover, Destination Type = Snapshot.
Note this restore method will Initialize Log Area. Check any appropriate “Other Settings”, the following screen is the defaults
Restore the snapshot files for recovery using either option (a) Revert Volume from Snapshot or option (b) Copy files. Option (a) is faster.
1. Revert Volume from Snapshot – this will roll a Volume back to a prior state and any data or snapshots added to the Volume after the Snapshot used to revert to are lost. At this time Reverting a Volume can only be done using the Azure Portal.
  
  ! Make sure SAP HANA is not running before reverting any volumes.
  
  If dealing with multiple Volumes make a note of the snapshot name you are reverting to as they all must have the same snapshot name.
2. Copy files - In this example, the files are copied from the “hidden” snapshot location in the filesystem.
```
# su - pr1adm
> cp -pr /hana/data/PR1/mnt00001/.snapshot/PR1_hourly__2022-03-31T210004-1084693Z/* /hana/data/PR1/mnt00001/.
```
3. Single file snapshot restore
  Alternatively Azure NetApp Files single file snapshot restore feature can be used to restore files without the need to copy any of them across the network
On the summary page, review any final details. Make sure you have copied/restored the snapshot files to the data area, if the copy has completed then press Finish to restore the system database.
When the recovery has finished a Recovery Execution Summary provides details of the recovery. The following screen shows a completed recovery of the SYSTEMDB.

! Note the message stating “recovering the system database from a storage snapshot invalidates all the tenant databases”. Tenant databases must now be recovered.
Start the recovery of the Tenant database
Choose the Tenant to recover from. At the time of writing, only a single tenant database is supported by SAP to recover from.
Choose to recover the tenant database to a specific data backup.
As there will be no log replay, continue to “Recover without the backup catalog”.
Specify the Backup to Recover, Destination Type = Snapshot.
Note this restore method will Initialize Log Area. Check any appropriate “Other Settings”, the following screen is the defaults
There is no need to restore the snapshot files to the data area as this was done when recovering the system database.
On the summary page, review any final details and press Finish to restore the system database.
When the recovery has finished a Recovery Execution Summary provides details of the recovery. The following screen shows a completed recovery of the tenant database.
The following screenshot shows the database after recovery with some services running.

Note, there is no process for PR2 running, this tenant still needs to be recovered

Repeat the steps 11-20 to recover any other tenants.

In our example, after recovering tenant PR2, the process list looks like the following:

A process listing can also be retrieved form the command line when logged in as the <sid>adm user.

> /usr/sap/hostctrl/exe/sapcontrol -nr 00 -function GetProcessList
01.04.2022 01:19:55
GetProcessList
OK
name, description, dispstatus, textstatus, starttime, elapsedtime, pid
hdbdaemon, HDB Daemon, GREEN, Running, 2022 04 01 01:06:14, 0:13:41, 713
hdbcompileserver, HDB Compileserver, GREEN, Running, 2022 04 01 01:07:04, 0:12:51, 1653
hdbindexserver, HDB Indexserver-PR1, GREEN, Running, 2022 04 01 01:14:54, 0:05:01, 3929
hdbindexserver, HDB Indexserver-PR2, GREEN, Running, 2022 04 01 01:17:39, 0:02:16, 5302
hdbnameserver, HDB Nameserver, GREEN, Running, 2022 04 01 01:06:14, 0:13:41, 731
hdbpreprocessor, HDB Preprocessor, GREEN, Running, 2022 04 01 01:07:04, 0:12:51, 1656
hdbwebdispatcher, HDB Web Dispatcher, GREEN, Running, 2022 04 01 01:07:05, 0:12:50, 1702
hdbxsengine, HDB XSEngine-PR1, GREEN, Running, 2022 04 01 01:15:11, 0:04:44, 4266

A process listing can also be retrieved form the command line when logged in as the <sid>adm user.

> /usr/sap/hostctrl/exe/sapcontrol -nr 00 -function GetProcessList
15.09.2019 23:51:43
GetProcessList
OK
name, description, dispstatus, textstatus, starttime, elapsedtime, pid
hdbdaemon, HDB Daemon, GREEN, Running, 2019 09 15 23:08:57, 0:42:46, 28998
hdbcompileserver, HDB Compileserver, GREEN, Running, 2019 09 15 23:09:28, 0:42:15, 29598
hdbindexserver, HDB Indexserver-PR1, GREEN, Running, 2019 09 15 23:21:34, 0:30:09, 31935
hdbindexserver, HDB Indexserver-PR2, GREEN, Running, 2019 09 15 23:37:51, 0:13:52, 36538
hdbnameserver, HDB Nameserver, GREEN, Running, 2019 09 15 23:08:57, 0:42:46, 29017
hdbpreprocessor, HDB Preprocessor, GREEN, Running, 2019 09 15 23:09:28, 0:42:15, 29601
hdbwebdispatcher, HDB Web Dispatcher, GREEN, Running, 2019 09 15 23:09:29, 0:42:14, 29648
hdbxsengine, HDB XSEngine-PR1, GREEN, Running, 2019 09 15 23:21:53, 0:29:50, 32071

Appendix – SAP HANA Data Volume locations

A detailed explanation of persistent data storage can be found in the “SAP HANA Administration Guide for SAP HANA Platform” - “Persistent Data Storage in the SAP HANA Database” section.

The following diagram is taken from the “Data and Log Volumes” sub-section. This shows the Directory Hierarchy for Persistent Data Storage (System with Multitenant Database Containers) for SAP HANA. Note the separation of System DB and Tenant DB files into logically grouped sub-directories. The volume names of tenant databases have a suffix to represent the database. For example, the indexserver volume for the first tenant database is hdb00002.00002, for the second database hdb00002.000003, and so on. For example, Tenant DB 1 data storage is grouped into both “hdb00002.00003” and “hdb00003.00003” sub-directories for the indexserver and xsengine respectively.