2039883 - FAQ: SAP HANA database and storage snapshots

Symptom

This SAP note provides answers to frequently asked questions about the SAP HANA database and its support of storage snapshots.

1. Where can I find more information about the SAP HANA database and the usage of storage snapshots?
2. Since when does the SAP HANA database support storage snapshots?
3. Is the Backint for SAP HANA API used to manage storage snapshots?
4. Is there a certification process for the SAP HANA database and its support of storage snapshots?
5. What are the advantages of storage snapshots in the SAP HANA database?
6. What are the disadvantages of storage snapshots in the SAP HANA database?
7. How can the storage snapshot support be enabled for the SAP HANA database?
8. How is I/O consistency across storage volume groups guaranteed in the SAP HANA database?
9. Is there a difference between a single and a multi-host SAP HANA database with regards to storage snapshots?
10. Which volumes of the SAP HANA database are affected by a storage snapshot?
11. In which operational state of SAP HANA database a storage snapshot can be created?
12. Is there a maximum number of supported storage snapshots in the SAP HANA database?
13. Is a storage snapshot recorded in the SAP HANA backup catalog?
14. How to use storage snapshots for recovery of the SAP HANA database?
15. Is it possible to perform a point-in-time recovery using log backups associated with a restored storage snapshot?
16. Is it possible to use a storage snapshot for recovery although it is not recorded in the SAP HANA backup catalog anymore?
17. What happens to the database internal snapshot after storage snapshot based recovery?
18. Does a database internal snapshot interfere with a snapshot used for the SAP HANA system replication?
19. Is storage snapshot lifecycle management included in the SAP HANA database backup lifecycle management?
20. Are there any recommendations about storage snapshot usage?
21. Is there something to consider using XFS file system?
22. What happens if SAP HANA database is simply restarted after restoring a storage snapshot?

Other Terms

HANA; Backup; Recovery; Storage Snapshot; FAQ;

Reason and Prerequisites

At least a SAP HANA database of HANA SPS 7 (revision 70) is used.

Solution

1. Where can I find more information about the SAP HANA database and the usage of storage snapshots?

To learn more about the usage of storage snapshots in the SAP HANA database please refer to the SAP HANA Administration Guide on http://help.sap.com/hana_platform.

2. Since when does the SAP HANA database support storage snapshots?

The SAP HANA database supports storage snapshots since HANA SPS 7 (revision 70).

Apart from this an interim solution with limited functional scope has been available since HANA SPS 3 revision 23 (see SAP Note 1703435). This is still supported but SAP recommends using the new approach.

3. Is the Backint for SAP HANA API used to manage storage snapshots?

No.

Storage snapshots are managed independently of the Backint for SAP HANA API.

4. Is there a certification process for the SAP HANA database and its support of storage snapshots?

No.

In contrast to the Backint for SAP HANA API, storage system vendors do not have to certify their solution at SAP ICC.

5. What are the advantages of storage snapshots in the SAP HANA database?

Basically storage snapshots are suitable to provide very fast data backups for a huge amount of data with a negligible impact to the network, overall I/O performance and the SAP HANA database itself.

Conversely storage snapshots are most suitable for fast database recovery (recovery-time-objective; RTO).

Dependent on the storage system vendor, storage snapshots offer a reduced disk space footprint due to delta store resp. de-duplication techniques. Please ask your storage vendor for more details.

6. What are the disadvantages of storage snapshots in the SAP HANA database?

In contrast to file-based or backint-based data backups, no database internal integrity check (checksum calculation) on page resp. block level is performed while a storage snapshot is created, i.e. storage snapshots might contain damaged data pages.

Compared to file-based or backint-based data backups, a storage snapshot will consider the entire data area of all SAP HANA database services and not only the payload of each service specific data volume.

Storage snapshots which are only available in the storage system and not replicated to another location or media cannot be used as backup in case of a disaster within the storage system itself.

7. How can the storage snapshot support be enabled for the SAP HANA database?

Storage snapshot support is enabled using a loose coupling between the SAP HANA database and the storage system. The creation of a storage snapshot is done in three steps that must be executed on the SAP HANA database site as well as on storage system level. The SAP HANA database offers SQL statements to PREPARE, CONFIRM and if needed ABANDON a storage snapshot.

Step 1: The SAP HANA database has to be requested to PREPARE itself for the storage snapshot. This is done by executing the SQL statement BACKUP DATA CREATE SNAPSHOT which has to be given once to an arbitrary HANA index server.

Step 2: The storage snapshot of the entire data area of all database services must be created using the storage system functionality.

Step 3: Finally the result of the storage snapshot creation must be reported to the SAP HANA database even if the storage snapshot failed, because the SAP HANA database has to clear internal states. For that purpose use the SQL statement "BACKUP DATA CLOSE SNAPSHOT BACKUP_ID <backup_id> SUCCESSFUL <external_id>" for confirmation or "BACKUP DATA CLOSE SNAPSHOT BACKUP_ID <backup_id> UNSUCCESSFUL [<string>]" for abandoning the snapshot.

Please be aware that the confirmation of a snapshot might result in an SQL error, if a database service was restarted during storage snapshot creation.

Following these steps most storage system vendors offer plugins that encapsulate the SAP HANA storage snapshot functionality, i.e. storage snapshots can be performed using the storage system administration console only. Please ask your storage vendor for more details.

8. How is I/O consistency across storage volume groups guaranteed in the SAP HANA database?

To guarantee I/O consistency across multiple storage volume groups, the SAP HANA database creates a database internal snapshot based on a system wide savepoint executed during the PREPARE step.

The database internal snapshot is stored in the data volumes of each database service and freezes the snapshot relevant data to be used for later recovery.

Thus no additional action on storage system level is necessary to synchronize disks, controllers etc.

9. Is there a difference between a single and a multi-host SAP HANA database with regards to storage snapshots?

No.

The database internal snapshot initiated by the SQL statement BACKUP DATA CREATE SNAPSHOT is created across all SAP HANA database services having their own data volume independent of the number of affected HANA hosts.

10. Which volumes of the SAP HANA database are affected by a storage snapshot?

A storage snapshot has to consider the data volumes of all SAP HANA database services. The log area must not be included in a storage snapshot to be able to perform a database recovery including the point-in-time option. Thus, log backups and not yet backed up log segments can be recovered after a snapshot has been restored.

Additional to the data volumes some SAP HANA database metadata information is needed. This information is recorded in an OS file located in the same directory as the name server data volume is stored.

11. In which operational state of SAP HANA database a storage snapshot can be created?

The SAP HANA database must be in operational state ONLINE to be able to PREPARE and CONFIRM a storage snapshot, i.e. if one of the SAP HANA database services is OFFLINE or unavailable the snapshot creation will fail.

12. Is there a maximum number of supported storage snapshots in the SAP HANA database?

No.

There is no upper limit of supported storage snapshots within the SAP HANA database. But have in mind that each storage snapshot is based on a database internal snapshot. At one time only one database internal snapshot for backup purpose is supported, i.e. while a storage snapshot is prepared no other storage snapshot or traditional data backup is possible. The database internal snapshot is dropped during CONFIRM or ABANDON processing but of course still available in the data area snapshotted before.

13. Is a storage snapshot recorded in the SAP HANA backup catalog?

Yes.

Every storage snapshot is recorded in the backup catalog of the SAP HANA database, even if the creation of the storage snapshot failed. The status of a snapshot is maintained according to the steps: PREPARE, CONFIRM or ABANDON.

14. How to use storage snapshots for recovery of the SAP HANA database?

In case of a database recovery the storage snapshot must be available in the data area. The SAP HANA database is not able to restore that storage snapshot from the appropriate storage system automatically. This must be done manually by the DBA.

A suitable storage snapshot can be determined either from the storage system administration console or the HANA backup catalog displayed in the recovery wizard of the SAP HANA studio.

The availability of the storage snapshot in the data area can be seen in the HANA backup catalog overview of the recovery wizard. A green symbol is displayed if the snapshot is available. If the snapshot is restored after the list of potential data backups including snapshots was assembled, press the REFRESH button to see if the snapshot is detected as available now.

15. Is it possible to perform a point-in-time recovery using log backups associated with a restored storage snapshot?

Yes.

On the one hand the SAP HANA database can be recovered using only a storage snapshot. In that case the log area will be initialized implicitly and no (redo) log will be applied. On the other hand a point-in-time recovery can be performed using log backups and not yet backed up log segments to reach an arbitrary point-in-time.

16. Is it possible to use a storage snapshot for recovery although it is not recorded in the SAP HANA backup catalog anymore?

Yes.

If the HANA backup catalog was re-created due to an exceptional situation a storage snapshot will not be recorded in the catalog anymore. Nevertheless a valid storage snapshot still can be recovered. But you need the storage system administration console to determine a suitable snapshot. After restoring the snapshot manually the recovery wizard will show the snapshot as available in the list of potential usable data backups and snapshots.

17. What happens to the database internal snapshot after storage snapshot based recovery?

The database internal snapshot will be dropped implicitly during database recovery. If the database recovery failed and must be repeated then the storage snapshot must be restored once again.

18. Does a database internal snapshot interfere with a snapshot used for the SAP HANA system replication?

No.

A database internal snapshot used for as a backup including storage snapshot support does not interfere with a snapshot used for SAP HANA system replication. Both kinds of database internal snapshots will subsist in friendly coexistence.

19. Is storage snapshot lifecycle management included in the SAP HANA database backup lifecycle management?

In contrast to traditional SAP HANA backups, the HANA backup lifecycle management is only taking into account the backup catalog specific part of a storage snapshot but not the physical deletion of the snapshot in the storage system itself.

But the SAP HANA database offers an SQL interface to maintain the HANA backup catalog including the physical deletion of dedicated backups and storage snapshots.

Ask your storage vendor if an integration of its storage snapshot implementation into the SAP HANA database is available.

20. Are there any recommendations about storage snapshot usage?

Yes.

• Due to the disadvantages of storage snapshots with regards to the missing integrity checks on block level, SAP strongly recommends to combine storage snapshots with traditional data backups. For example perform a storage snapshot once a day and once a week a traditional backup to the file system or to a 3^rd party backup tool. If the traditional backup fails the storage snapshots since the last successful traditional backup are potentially affected to be corrupt as well.
• Please note that a storage snapshot available only in the storage tool itself is no backup. Ensure that a snapshot is also available on a remote destination to be protected against failure of the entire storage system.
• For fast database recovery keep at least one storage snapshot nearby the SAP HANA database. But ensure that this snapshot is also available on a remote destination (see above).
• Confirm a storage snapshot as fast as possible to avoid unintended growing of the data area caused by the copy-on-write mechanism of the SAP HANA database. Have in mind that HANA implements a shadow page scheme with regard to the persistence layer, i.e. dirty pages will not be written to the same position again and backup relevant pages will be kept until the data backup resp. snapshot is finished.

21.  Is there something to consider using XFS file system?

Yes.

The journaling file system XFS requires an explicit step to flush the journal to disk timely before a consistent storage snapshot including the XFS metadata can be taken. Typically xfs_freeze with root credentials needs to be executed which is not done by SAP HANA database. If that step is omitted it’s quite likely that the storage snapshot cannot be used for recovery due to inconsistencies of the XFS file system.

21. What happens if SAP HANA database is simply restarted after restoring a storage snapshot?

If a storage snapshot is restored to the HANA data area and a restart is executed instead of a recovery, SAP HANA database will reject the database internal snapshot and try to start on the last savepoint contained in the data area that typically will not match to the log area. In addition to that it’s strongly recommended to disable the HANA auto start feature while recovering a storage snapshot.

Header Data

Released On	17.03.2015 08:50:57
Release Status	Released for Customer
Component	HAN-DB-BAC SAP HANA Backup & Recovery
Other Components	HAN-DB SAP HANA Database
Priority	Recommendations / Additional Info
Category	FAQ