The SAP HANA Disaster Recovery Failover Runbook.
The exact five-step failover procedure 912 uses on SAP Business One disaster recovery engagements. Manual failover gate to prevent split-brain corruption. ETIMS-ready DR continuity. Built from fulfilled DR work for a Kenyan manufacturer — published so SAP administrators can stress-test their own DR plans against a real runbook.
- Five-step failover procedure with the exact commands (hdbnsutil -sr_state, hdbnsutil -sr_takeover)
- Failback procedure for when the primary site is repaired
- Prerequisites checklist (hardware, MPLS, licensing, ETIMS activation)
- Honest residual-risk framing — what async replication protects and what it doesn't
What you get
Web runbook plus PDF download for SAP administrators validating DR readiness.
Web version
SAP HANA DR Runbook web versionAccess
The complete runbook and readiness assessment are available on this page without an email gate.
Next action
Score your readiness, then book a discovery call to review the weakest failover gate.
Score your own readiness.
This is ungated on purpose. Use it directly in the browser, then turn the result into an internal action plan.
Score-to-call bridge
Bring your weakest failover gate to the discovery call.
If your score is low, the useful conversation is not a generic SAP pitch. We review the exact failed gate: HANA sizing, manual takeover procedure, ETIMS continuity, user notification, failback, or backup evidence. The result is a clear next step: tabletop drill, DR runbook cleanup, or implementation scope.
Recommended path
- 1. Complete the readiness score on this page.
- 2. Review the five-step runbook and prerequisites on this page.
- 3. Book a call with the weakest gate as the agenda.
The Procedure
Five steps from primary outage to DR live.
The procedure is deliberately manual at the takeover gate. Automatic failover under flapping MPLS links is where SAP environments lose data permanently via split-brain corruption.
Confirm the primary outage
Verify the primary site is genuinely down and not just experiencing transient connectivity. Check replication state and the last-applied timestamp with hdbnsutil -sr_state. This gives you the data-loss exposure window before you commit to a failover.
Notify management and key users
Communicate that failover is being executed. Acknowledge the potential data gap (asynchronous replication exposes seconds-to-minutes of data loss in normal link conditions). Communications-discipline at this step prevents finger-pointing later.
Execute the takeover
On the DR HANA node, run hdbnsutil -sr_takeover. Update DNS to point client traffic at the DR site. Flush workstation DNS caches across the user base — automated via login script or manual depending on environment.
Start SAP Business One & verify ETIMS
Start SAP Business One services on the DR application server. Before opening access to end users: log in, post a test invoice, verify ETIMS-compliant invoicing works against KRA infrastructure. Only after all three pass should users be re-onboarded.
Fail back when primary is repaired
Register the recovered primary site as the new secondary. Resync the data direction. Execute the failback during an agreed maintenance window — the same takeover procedure runs in reverse. Document the data delta for the audit trail.
Before You Failover
Prerequisites checklist.
The runbook assumes these are in place. If any are missing, the failover may complete but production won't recover cleanly.
Residual Risk Framing
What this runbook protects against — and what it doesn't.
Honest framing of the trade-offs. The runbook works as designed; the failure modes below sit outside its scope and have to be mitigated separately.
Asynchronous = seconds to minutes of data loss exposure
Async replication protects daily SAP performance but does not deliver zero-RPO. If the MPLS link is down at the moment of primary failure, exposure equals the MPLS outage window. We document this upfront rather than promising zero data loss we cannot deliver.
Manual failover is deliberate — never automate it
Automatic failover under flapping links is where SAP environments lose data permanently via split-brain corruption. The few extra minutes the manual gate adds buys you a guarantee of data integrity. Trading minutes for integrity is the right trade.
ETIMS at DR is not optional for Kenyan operations
A SAP DR plan that ships without ETIMS configured at the DR site is broken — tax-compliant invoicing breaks the moment you fail over. Configure and test ETIMS at DR before going live.
Related
Need 912 to implement this DR for you?
The runbook is published so SAP administrators can stress-test their own plans. If your team would rather have us design, implement, test, and document the DR architecture end-to-end, the engagement model is on the SAP HANA DR service brief.