Disaster recovery
Disaster recovery (DR) is the plan for restoring SAP after the loss of an entire site or a catastrophic failure, as opposed to HA, which handles component failures within a site. For a system that runs the business, a tested DR plan is non-negotiable.
A DR plan that has never been executed is an assumption, not a capability.
- DR ensures that if the primary data center is lost, the SAP system can be brought back at a secondary site within agreed limits on…
- Common approaches include HANA System Replication to a DR site, storage-level replication, and regular offsite backups.
- RPO (Recovery Point Objective): how much data loss is tolerable, drives replication frequency.
- Watch out: Protecting the database but not integrations/secrets.
What DR must achieve
DR ensures that if the primary data center is lost, the SAP system can be brought back at a secondary site within agreed limits on data loss and downtime. Because all state lives in the database, DR centers on replicating and recovering the database, plus rebuilding the application tier and reconnecting integrations.
RPO and RTO
- RPO (Recovery Point Objective): how much data loss is tolerable, drives replication frequency.
- RTO (Recovery Time Objective): how quickly the system must be back, drives standby readiness.
DR mechanisms
Common approaches include HANA System Replication to a DR site, storage-level replication, and regular offsite backups. Application-server configuration is kept reproducible so the app tier can be rebuilt or activated at the DR site.
Test the plan
A DR plan that has never been executed is an assumption, not a capability. Regular DR drills, actually failing over and validating, are what turn the plan into real resilience.
Common pitfalls
- Protecting the database but not integrations/secrets.
- RPO/RTO assumed rather than agreed with the business.
- Never rehearsing the failover.