India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
SAP Disaster Recovery Across Indian Regions with HANA Replication
SAP disaster recovery is the ability to bring SAP production back in a different region after the primary region or site is lost, within agreed RPO and RTO. NTSPL replicates HANA asynchronously to a second Indian region, recovers application and central services tiers there, switches DNS and interfaces, and runs timed drills that produce evidence for boards and auditors.
Delivered on
In scope
What Zonal HA Cannot Recover and Why SAP DR Is Harder Than VM DR
Zonal HA protects against a host or zone failure, but not against a region-wide network event, a data-centre fire, or an operator error that corrupts the primary and its synchronous secondary at the same moment. For SAP, recovery in another region is harder than for most workloads: HANA must be current, ASCS and application servers must start with the right profiles, the transport directory and interface certificates must exist, and dozens of plant, bank and GST connections must point to new addresses.
NTSPL designs SAP DR as a tier-three HANA secondary in the paired Indian region, fed by asynchronous system replication, with application servers recovered from replicated images or built from code on demand. DNS names, not IP addresses, carry every connection so the switch is one change set. Each design ends with a timed drill that brings SAP up in the DR region, runs a sample of business transactions and fails back.
When SAP Needs a Second-Region Recovery Design
Signals you need SAP Disaster Recovery
- SAP production runs in a single region and the board risk register lists ERP loss as a top-five risk.
- A DR site exists on-prem or in cloud but has not been drilled in more than 12 months.
- The required RTO for SAP is under 4 hours and RPO is under 30 minutes.
- A parent company, lender or regulated customer asks for evidence of a tested ERP DR plan.
- More than 50 external interfaces would need address changes in a DR event.
When to choose something else
- The concern is a single host or zone failure; zonal SAP high availability is cheaper and faster.
- The main threat is ransomware or accidental deletion; replication copies corruption, so immutable SAP backups are the first control.
- Non-SAP applications are the main DR scope; a general workload DR design across the estate fits better.
What NTSPL Builds in the SAP DR Region
HANA DR replication
Async HSR from the primary or zonal secondary to a DR host in the second region, using multi-target or multi-tier topology and sized for peak log generation.
SAP application tier recovery
ASCS, ERS and application servers recovered from replicated disks or rebuilt from Terraform, with profiles and kernel identical to production.
Shared files and transports
Replication of /sapmnt, /usr/sap/trans and interface file directories to the DR region on a schedule that matches RPO.
Name and interface switch
DNS records, load balancer frontends, SAP router, Cloud Connector and partner endpoints switched with one prepared change set.
Drill and evidence
Scripted drill with business test cases, timings, failback steps and a signed drill report.
Three-Tier HANA Replication with Regional Recovery of the SAP Stack
Three-Tier HANA Replication with Regional SAP Stack Recovery
Production HANA replicates synchronously to a zonal secondary and asynchronously to a tier-three host in the DR region. On declaration, the DR HANA takes over, the application tier starts from replicated or code-built hosts, and DNS points users and interfaces to the DR region.
Select any component
Three-Tier HANA Replication with Regional SAP Stack Recovery: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
SAP DR Region Pairs and Tooling in India
Mumbai to Hyderabad is the usual pair; application servers replicate with Elastic Disaster Recovery and EFS replication carries /sapmnt and transport files.
Central India to South India is the common pair; Site Recovery protects app servers, and Azure Business Continuity Center gives one view of replication health across SAP resources.
Mumbai to Delhi keeps DR inside India; application tiers are rebuilt from Terraform with Backup and DR Service protecting their disks, and shared SAP files are synced to Filestore in Delhi.
DR Choices That Trade Cost Against RTO
Hot, warm or rebuild-on-demand DR HANA
For RTO under 2 hours, run a DR HANA host continuously with replication and preload. For RTO of 4 to 8 hours, run a smaller DR host without preload and resize at takeover where possible. Restoring HANA from backups in the DR region suits RTO above 12 hours and is the cheapest option, but RPO then depends on log backup frequency.
Multi-target or multi-tier replication
Prefer multi-target replication from the primary, so the DR site keeps receiving logs when the zonal secondary is down or being patched. Multi-tier, where the zonal secondary forwards to DR, is simpler but makes DR depend on the secondary. Check that your HANA revision supports multi-target with the cluster agents you use.
Application tier recovery method
Replicating application server VMs with provider DR tools suits teams that patch inconsistently. Rebuilding from Terraform with a replicated /sapmnt is cleaner and cheaper when infrastructure is already code. In both cases, keep the SAP kernel and profiles in sync, and test that the DR ASCS can start with DR-region hostnames.
Failback approach
Plan failback before the first drill. Reverse HSR from DR to the original primary needs a full data shipment after a real disaster, which can take hours for large databases. Size the replication link for both directions and schedule failback for a weekend unless the DR region cannot carry production load.
DR Build and First Drill in Six Weeks
Recovery targets and declaration rules
Agree RPO, RTO, declaration authority and which systems are in DR scope.
DR region foundation
Extend network, identity, keys and DNS into the DR region and build hosts from code.
Replication setup
Configure async HSR, file replication and app-tier protection, and measure lag through a month-end.
Interface and DNS change set
Prepare DNS records, partner endpoint changes and certificate copies for the DR region.
First drill and failback
Run a timed drill with business tests, fail back and issue the drill report.
What you receive
DR Drill Measures for SAP
| KPI | Typical target |
|---|---|
| Measured RTO in drill | Within agreed RTO, typically 1 to 4 hours |
| Replication lag at month-end peak | Below RPO, typically under 15 minutes |
| Business test cases passed in DR | 100 percent of the drill set |
| Interfaces working after switch without manual fix | At least 95 percent |
Reasons SAP DR Fails on the Day
| Risk | How NTSPL prevents it |
|---|---|
| Interfaces point to IP addresses and fail after the switch | The readiness interface register is used to convert every endpoint to DNS names before DR go-live, and the drill tests each critical partner. |
| Replication falls behind during month-end and RPO is breached unnoticed | Lag alerts fire well below the RPO threshold and month-end lag is reported each cycle. |
| DR host is too small to handle real production load | Resize procedures are tested in drills, and minimum DR capacity is agreed with process owners for a defined degraded period. |
HANA system replication or backup restore for SAP disaster recovery?
HSR to a DR region gives RPO in minutes and RTO in one to two hours, because the DR database is already current and only needs takeover. It costs a running DR host and replication bandwidth. Backup restore in the DR region costs far less on standby, but RTO grows with database size, often 6 to 12 hours for a 3 TB HANA, and RPO equals your log backup interval plus copy delay. For S/4HANA production supporting plants and dispatch, NTSPL recommends HSR. Backup restore is acceptable for BW, development and systems where the business can tolerate a day's outage.
Key facts: SAP Disaster Recovery
SAP Disaster Recovery in Practice
2 SAP Disaster Recovery scenarios, from Pumps & valves and Cables & wires, plus related platform case studies.
Pumps and valves maker brings S/4HANA up in Delhi in 1 hour 48 minutes
Cables and wires maker replaces an undrilled on-prem DR with Chennai SAP recovery
Multi-specialty hospital cuts HIS recovery time from 2 days to 38 minutes
3PL operator cuts warehouse system recovery time from 2 days to 45 minutes
SAP Disaster Recovery: Frequently Asked Questions
What does SAP DR on cloud cost to run?
Standby cost depends on the DR HANA size and whether app servers run continuously. A typical warm design with a smaller DR HANA host and app servers off adds 30 to 50 percent to production infrastructure cost. Build and first drill effort is usually 25 to 40 consultant-days.
Which Indian region pairs do you use?
Usually AWS Mumbai with Hyderabad, Azure Central India with South India, and Google Cloud Mumbai with Delhi. These keep SAP data inside India for DPDP Act 2023 data mapping and for RBI, SEBI or IRDAI regulated group entities.
How often should SAP DR be drilled?
At least twice a year, plus after any major upgrade such as an S/4HANA release change. One drill a year should include a full business test with key users. Drills are scheduled outside close and GST filing weeks.
Who decides to declare a disaster?
A named executive, usually the CIO with the CFO or COO, based on criteria in the runbook such as expected primary outage over two hours. Writing this down prevents an hour of debate while plants wait.
Can DR also help with CERT-In requirements?
DR itself is not a CERT-In requirement, but drills produce event logs and incident timelines. NTSPL keeps those logs in India for at least 180 days and uses the same timeline format needed for a 6-hour CERT-In report if a cyber incident triggers DR.
Does replication protect us from ransomware?
No. Replication copies encryption or deletion to DR within minutes. Ransomware recovery depends on immutable backups and clean restore points, so NTSPL designs SAP DR and SAP backup together.