Sap Disaster Recovery Plan Template

Standard Operating Procedure: SAP Enterprise Disaster Recovery Execution

Document ID: SOP-TR-DR-SAP-042
Effective Date: October 24, 2023
Version: 4.2.0
Review Cadence: Semi-Annual
Author: Julian Vance, Chief Architect, Template Registry

---

1. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional-grade framework for executing a Disaster Recovery (DR) failover and failback sequence for mission-critical SAP enterprise environments (ERP, S/4HANA, BW/4HANA). The purpose of this document is to establish a rigorous, repeatable protocol that ensures Return Point Objective (RPO) $\le$ 15 minutes and Recovery Time Objective (RTO) $\le$ 4 hours in the event of a primary datacenter outage, infrastructure corruption, or catastrophic regional failure.

---

2. Scope & Prerequisites

2.1 Scope

• Applies to all Tier-0 and Tier-1 SAP landscapes managed under the Template Registry enterprise architecture.
• Encompasses database tier (SAP HANA System Replication), application tier (ABAP/Java Central Services and Application Servers), and storage tier (Synchronous/Asynchronous block replication).

2.2 Prerequisites & Required Tooling

• Access Control: Privileged access management (PAM) tokens for root, sidadm, and hdbadm.
• Software/Tools:
  • SAP HANA Studio / Cockpit / hdbsql
  • SAP Landscape Management (LaMa) or automated orchestration scripts
  • Infrastructure-as-Code (Terraform/Ansible) control plane for DR target regions
• Network Validation: Verified site-to-site VPN / ExpressRoute circuits with a baseline latency of $< 5\text{ms}$ and redundant routing tables.

---

3. Roles & Responsibilities (RACI Matrix)

---

4. Step-by-Step Procedure

Phase 1: Incident Assessment & Declaration

• 1.1 Convene the Disaster Recovery Steering Committee via the emergency bridge.
• 1.2 Verify primary site isolation and confirm unrecoverable fault conditions.
• 1.3 Authorize formal DR declaration and log timestamp in the Incident Management System.

Phase 2: Database Tier Failover (SAP HANA SR)

• 2.1 Access the secondary (DR) database host via secure shell using hdbadm.
• 2.2 Check current HANA System Replication (HSR) status:

  hdbnsutil -sr_state
  

• 2.3 Break replication and promote the secondary database to primary:

  hdbnsutil -sr_takeover
  

• 2.4 Verify database initialization and SQL port availability (Port 3<Instance>15):

  R3trans -d
  

Phase 3: Application Tier Orchestration

• 3.1 Mount persistent storage volumes (NFS/SAN) in the DR compute cluster.
• 3.2 Update virtual IP (VIP) or DNS entries to point to the DR SAP ASCS (ABAP Server Central Services) node.
• 3.3 Start Central Services (ASCS/ERS) on the DR node:

  sapcontrol -nr <ASCS_Instance> -function StartSystem
  

• 3.4 Validate message server and enqueue server health:

  sapcontrol -nr <ASCS_Instance> -function GetSystemList
  

Phase 4: Application Server Spin-up & Smoke Testing

• 4.1 Execute automated deployment scripts to provision primary and secondary application servers.
• 4.2 Start application server instances across the DR cluster:

  startsap ALL
  

• 4.3 Execute core functional validation transactions via GUI/RFC:
  • SM21 (System Log analysis)
  • SM59 (RFC Destination checks)
  • SICK (Installation check)
• 4.4 Obtain sign-off from Business Process Owners for integrated data integrity.

---

5. Quality Assurance & Pro-Tips

Best Practices

• Pre-Sync Configurations: Maintain identical /usr/sap/trans, profile parameters, and secure store keys (secstore.properties) across both primary and DR sites using automated configuration management tools.
• Read-Access-Only (RAO): Keep secondary HANA sites in active-enforced continuous replay mode to minimize takeover latency.

Common Pitfalls

• Split-Brain Scenarios: Never promote a secondary HANA database without definitively confirming the primary database is fully fenced and isolated at the network level.
• Secure Store Mismatches: Forgetting to synchronize the crypto keys can cause instant decryption failures upon application tier startup.

Metric Thresholds

• RPO Threshold: $\le 15\text{ minutes}$ (Enforced via synchronous/asynchronous replication alerts).
• RTO Threshold: $\le 4\text{ hours}$ end-to-end execution.

---

6. Frequently Asked Questions (FAQ)

Q1: What should be done if the hdbnsutil -sr_takeover command fails with a split-brain warning?
A: Terminate any lingering processes on the primary node, ensure stonith/fencing mechanisms have completely powered off the primary host, and force the takeover using the --force flag only after explicit sign-off from the Database Architect.

Q2: How are transport routes handled during a DR failover scenario?
A: The transport directory (/usr/sap/trans) must be mounted via replicated block storage. If utilizing asynchronous file-level replication, verify the mount point is read-write enabled in the DR region before releasing users into the system.