Home > Workload Solutions > SAP > Guides > SAP HANA TDI Guides > Business Continuity and Disaster Recovery with Dell PowerMax Storage for SAP HANA TDI Deployments > Disaster recovery in SAP HANA
Most customers maintain a local or remote copy of the data for DR protection of their mission-critical applications and SAP HANA in-memory database when they are using the database in TDI deployments with PowerMax arrays.
SAP HANA offers three levels of DR support:
Each level of support addresses different RPOs within the required recovery time objective (RTO). RPO denotes the point of consistency to which SAP HANA must recover and RTO denotes the time that is allowed for a recovery of the SAP HANA system to a specified point of consistency.
SAP HANA offers DR support through backups or SAP HANA system replication, while SAP HANA storage-based replication enables customers to seamlessly integrate SAP HANA into their existing business continuity solutions based on replication technologies with federated DR strategies.
Backups protect the primary SAP HANA persistence against a storage failure. Therefore, the SAP HANA backup target should never be on the same storage array as the primary SAP HANA persistence. Backup systems can typically replicate the backup storage to a remote system to protect against a site failure.
With SAP HANA backups, the RPO can be minutes or hours, depending on the frequency of your SAP HANA backups. The RTO with backups can be several hours, because an SAP HANA backup must be restored to the persistence and then read into memory before the database is available.
Note: Dell Technologies offers SAP HANA backup solutions based on Dell PowerProtect and Dell Data Domain data protection technology. For more information, see PowerProtect Data Manager: SAP HANA Agent Backup and Recovery.
SAP HANA system replication is an application-based DR solution in which a secondary standby SAP HANA system is configured as an exact copy of the active primary system. Each secondary system must consist of the same number of active SAP HANA nodes. As with storage-based replication, SAP HANA system replication requires a reliable connection between the primary and secondary sites. The replication technology supports multiple replication modes: synchronous, synchronous in-memory, and asynchronous.
With SAP HANA system replication, only the database content is replicated to the secondary site.
Note: Beginning with SAP HANA Support Package Stack (SPS) 09, dynamic tiering is available with SAP Sybase IQ.
Storage-based replication in SAP HANA TDI deployments provides a reliable, consistent, and convenient method to protect against a site failure. The SAP HANA primary persistence is replicated to a secondary site using storage-based replication technologies. Depending on your RTO and RPO requirements and the distance between the primary and secondary site, implementation of synchronous storage-based replication (RPO=0) or asynchronous storage-based replication (RPO≥0) is possible. If a disaster occurs, the RTO is typically the time it takes to start up the SAP HANA database at the secondary site.
SAP HANA storage-based replication offers benefits that are not provided by system replication:
You can also integrate replication of components such as the operating system boot devices, the SAP HANA shared file system (which includes the binaries and configuration files), and applications other than SAP HANA into a storage-based replication strategy, enabling a federated DR strategy.
This solution guide describes several use cases for SAP HANA local and remote storage-based replication on PowerMax storage arrays. See Business continuity best practice use cases for local and remote SAP HANA storage-based replications.
Note: For more information about the different DR solutions and their advantages and disadvantages, see the SAP HANA Administration Guide.