Your company has decided that all SAP Business Suite and SAP BW systems will be migrated to the SAP HANA database. It is your task to investigate what is the best backup and recovery strategy for the SAP HANA databases. Therefore, you need to know the backup and recovery concept of the SAP HANA database.
The normal database backup and recovery principles apply to SAP HANA. The SYSTEMDB and all tenants are separate databases, which can be individually backed up and restored. SAP HANA supports the following backup and recovery capabilities:
- Complete, differential, and incremental backups
- Automatic redo log backups
- Integrity checks for backups
- Backup lifecycle management
- Recovery to the most recent state, a specific point-in-time, or a specific data backup
- Backup and recovery using third-party tools
- Database copy using backup and recovery
With the tools SAP HANA cockpit, hdbsql and the ABAP transaction DBACOCKPIT, you can create backups manually or schedule backups.
Data and log backups are performed while the SAP HANA database is online. The performance impact of backups on system performance is negligible, and users can continue to work while the data backup is running.
The file system backup location for data and log is specified system-wide, and must be valid for all nodes of the SAP HANA system. Both the data and the log location should be located on external media.
basepath_databackup holds the location where the data backups are written. By default, the location for data backup files is
$(DIR_INSTANCE)/backup/data. If you change the backup location in
basepath_databackup, the change occurs immediately.
Backups of tenant databases are always created in sub-directories of
The default backup destination can only be changed for file-based backups. Backups made using third-party tools always use the destination
/usr/sap/<SID>/SYS/global/hdb/backint. Because of this, you cannot change the backup destination for third-party tools.
The automatic log backups are written to the location mentioned in the parameter
Integrity tests are performed while the database backup is running. If these checks are successful, the data is written to the backup destination. The data areas of all running SAP HANA services are individually backed up, these backup run in parallel. This is also true for an SAP HANA scale-out system were all data areas of all services on all hosts are backed up in parallel.
A complete data backup includes all the data that is required to recover the database to a consistent state. This includes both business data and administrative data. In a data backup, only the actual data is backed up; unused space in the database is not backed up. A data backup reflects the consistent database state from the time at which the data backup was started.
The system database plays a central role. It can initiate backups of both the system database itself and of individual tenant databases. A tenant database can create its own backups without the need to connect through the system database. System database and tenant databases have their own backup catalogs.
By default, the configuration files are not part of a data backup. If required, the data backup can easily be configured to include the configuration files.
In a recovery situation, configuration files can help to identify and restore the customer-specific changes. The configuration files are not essential to perform a recovery. If you want to use a customer-specific configuration, reconfigure the recovered system using the SAP HANA cockpit.
SAP HANA Backup Strategy
To ensure data security, it is necessary to perform data and log backups at appropriate intervals. We recommend that you perform:
- Daily a complete data backup, or at least once a week, in a 4-week backup cycle
- Daily a delta data backup (incremental or differential) during the week
- Daily automatic log backups
This creates four backup generations in a 28-day cycle. After the 28 days, the backup media can be reused.
Depending on factors such as database size, availability of backup destination, and other factors, you can define a suitable backup strategy.
You can use a simple backup strategy consisting of regular complete database backups and log backups. To recover from a media error (disk), you restore the database from a complete data backup (preferably from the last one), recover log backups written during and after this backup, and recover the most recent log entries from the log area to completely recover the database.
In a system where delta backups can reduce backup time, you can perform complete backups less often and replace them with delta backups. To recover from a media error (disk), you restore the database from a complete data backup (preferably from the last one), recover the necessary delta backups, recover log backups written during and after this delta backup, and recover the most recent log entries from the log area to completely recover the database.
Example – Complete Backups Versus Complete and Delta Backups in a 28-Day Backup Cycle
- Daily Complete backup = 10 TB
- Daily Log backups = 250 GB
- Daily Incremental backup = 500 GB
|Backup Action||Complete backup strategy||Complete with Incremental backup strategy|
|Complete backups||28 x 10 TB = 280 TB||4 x 10 TB = 40 TB|
|Incremental backups||n/a||24 x 500 GB = 12 B|
|Log backups||28 x 250 GB = 7 TB||28 x 250 GB = 7 TB|
|Total storage size||287 TB||59 TB|
As you can see in this small calculation example, using incremental or differential backups in your backup cycle can significantly reduce the storage requirements.
Release Compatibility of SAP HANA Backups
In the following situations, backups from previous SAP HANA releases can be used for a database recovery. The source version must be equal to or lower as the target version. This means you can restore a backup created on SAP HANA SPS05 into an SAP HANA SPS07 database system.
When restoring a backup of an SAP HANA single-container system to an SAP HANA multi-container system, the restore is automatically recovered to a tenant database. Restoring a backup of an SAP HANA single-container system to a SYSTEMDB is not supported.