Discovering Disaster Recovery in SAP HANA

Backups are one of the key disaster recovery features offered by SAP HANA.

SAP HANA uses in-memory technology, but of course, it fully persists any transaction that changes the data, such as row insertions, deletions, and updates, so it can resume from a power outage without loss of data. SAP HANA persists two types of data to the storage system, transaction redo logs and data changes in the form of savepoints.

A transaction redo log is used to record a change. To make a transaction durable, it is not required to persist the complete data when the transaction is committed. Instead, it is sufficient to persist the redo log. On failure, the most recent consistent state of the database can be restored by replaying the changes recorded in the log, redoing completed transactions, and rolling back incomplete transactions.

A savepoint is a periodic point in time when all the changed data is written to storage, in the form of pages. One goal of performing savepoints is to speed up restart. When starting a system, logs need not be processed from the beginning, but only from the last savepoint position. Savepoints are coordinated across all processes (called SAP HANA services) and instances of the database to ensure transaction consistency. By default, savepoints are performed every five minutes, but this value is configurable.

Savepoints normally overwrite older savepoints, but it is possible to freeze a savepoint for future use. This is called a snapshot. Snapshots can be replicated in the form of full data backups, which can be used to restore a database to a specific point in time. This can be useful in the event of data corruption, for instance. In addition to data backups, smaller periodic log backups ensure the ability to recover from fatal storage faults with minimal loss of data.

Savepoints can be saved to local storage, and the additional backups can be saved to backup storage. Local recovery from the crash uses the latest savepoint, and then replays the last logs, to recover the database without any data loss. If the local storage was corrupted by the crash, it is still possible to recover the database from the data and log backups, possibly with some loss of data. Regularly shipping backups to a remote location over a network or using couriers can be a simple and relatively inexpensive way to prepare for a disaster. Depending on the frequency and shipping method, this approach may have a recovery time ranging from hours to days.

SAP HANA offers disaster recovery support for storage replication solutions provided by hardware partners.

One drawback of backups is the potential loss of data between the time of the last backup and the time of the failure. A preferred solution is to provide continuous replication of all persisted data. Several SAP HANA hardware partners offer a storage-level replication solution that delivers a backup of the volumes or file system to a remote, networked storage system. In some of these vendor-specific solutions, which are certified by SAP, the SAP HANA transaction only completes when the locally persisted transaction log has been replicated remotely. This is called synchronous storage replication. Synchronous storage replication can be used only where the distance between the primary and backup site is relatively short (typically 100 kilometers or less), allowing for sub-millisecond round-trip latencies.

System replication is available in every SAP HANA installation offering inherent disaster recovery support.

System replication is an alternative high availability solution for SAP HANA that provides an extremely short RTO, and is compatible with all SAP HANA hardware partner solutions. System replication employs an "N+N" approach, with a secondary standby SAP HANA system with the same number of active nodes as the active primary system. Each service and instance of the primary SAP HANA system communicates pairwise with a counterpart in the secondary system.