Keep SAP running through failures, and recover fast when a region goes down.
We design, build and test high availability, disaster recovery and backup for SAP HANA and SAP applications on AWS, Microsoft Azure and Google Cloud. You get recovery targets agreed with the business, an architecture that meets them and regular tests that prove it.
Why resilience has to be designed, not assumed
SAP is usually the system the business cannot do without, and an outage stops orders, shipments and payroll. The cloud gives you zones, regions and native backup services, but none of them protect SAP on their own. HANA needs replication configured, clusters need correct fencing, application servers need a plan to fail over, and backups need to be restorable within the time the business expects. For Sri Lankan organisations there is also distance to consider: there is no hyperscaler region in Sri Lanka, so primary and DR sites are typically in India or Singapore.
Unclear recovery targets
Without an agreed recovery point objective and recovery time objective, nobody knows whether the design is good enough or overbuilt.
Single zone deployments
A production system in one Availability Zone has no protection if that zone fails.
Clusters that fail over badly
Pacemaker clusters with wrong fencing or timeouts can cause split brain or long outages instead of preventing them.
Untested DR
A DR site that has never been switched to is a plan on paper, not a capability.
What we do
We cover the full resilience stack for SAP and HANA, from local high availability to cross-region recovery and backup.
Recovery target workshop
We work with business and IT owners to set RPO and RTO for each system. Those targets then drive the design and the cost of resilience.
HANA system replication
We configure SAP HANA system replication between zones and regions, choosing synchronous or asynchronous modes to fit distance and targets. We size the secondary and set up monitoring of replication status.
Pacemaker clusters
We build and test Pacemaker clusters on SUSE Linux Enterprise Server for SAP or Red Hat Enterprise Linux for SAP for HANA and for ASCS and ERS. Fencing, virtual IP handling and timeouts follow each cloud's reference guidance.
Cross-region disaster recovery
We set up a secondary region with HANA replication, replicated application servers and network routes. We write the failover and failback runbooks and rehearse them.
Backup and restore
We set up SAP certified Backint backups to cloud storage, plus snapshots where they fit. Retention, immutability and encryption follow your policy, and restores are tested on a schedule.
DR testing and reporting
We run planned DR tests, measure the actual recovery times and report them against targets. Gaps go into a remediation plan.
How it works
- 1
Assess
We review your current landscape, backup setup and any past incidents. We agree RPO and RTO per system with the business.
2 to 3 weeks - 2
Design
We produce a resilience architecture covering zones, regions, replication, clustering and backup. It includes the cost and operational impact of each option.
2 to 4 weeks - 3
Build
We deploy clusters, replication, backup agents and DR infrastructure, ideally as infrastructure as code. Each component is tested as it is built.
4 to 8 weeks - 4
Test
We run failover tests, restore tests and a full DR rehearsal. Results are measured and documented against the agreed targets.
1 to 2 weeks - 5
Operate and retest
We monitor replication and backups as part of daily operations and repeat DR tests at an agreed frequency, usually at least once a year.
Ongoing
Native building blocks on each cloud
SAP HANA system replication and Pacemaker work on all three clouds; backup and DR services differ by provider.
| Need | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Local high availability | Multiple Availability Zones with Pacemaker and overlay IP | Availability zones with Pacemaker and Azure Load Balancer | Multiple zones with Pacemaker and an internal passthrough Network Load Balancer |
| SAP certified HANA backup | AWS Backint Agent for SAP HANA to Amazon S3 or AWS Backup | Azure Backup for SAP HANA (Backint and snapshots) | Backint feature of Google Cloud's Agent for SAP to Cloud Storage |
| Snapshot and managed backup | AWS Backup | Azure Backup with Recovery Services vault | Google Cloud Backup and DR Service |
| Cross-region replication for application servers | AWS Elastic Disaster Recovery | Azure Site Recovery | Persistent Disk Asynchronous Replication or Backup and DR Service |
| Database replication across regions | SAP HANA system replication (asynchronous) | SAP HANA system replication (asynchronous) | SAP HANA system replication (asynchronous) |
The SAP angle: who owns recovery
Under RISE with SAP, SAP runs the infrastructure on the hyperscaler you chose and is responsible for high availability, backup and disaster recovery within the options in your contract. SAP's published service description for RISE private cloud DR sets an RPO of 0 minutes for short distance DR and 30 minutes for long distance DR, with a standard RTO of 12 hours and an optional 4 hour RTO. Your job is to choose the right option, check it covers your business needs and plan recovery for everything around SAP, such as SAP BTP services, interfaces and non-SAP systems. If you run ECC or SAP S/4HANA yourself on a cloud subscription, the whole design is yours, and that is where we do most of the build work.
- Advice on RISE with SAP DR options and what they mean for your business
- Full HA and DR build for self-managed ECC and SAP S/4HANA on AWS, Azure and Google Cloud
- DR planning for integrations, SAP BTP and surrounding systems
- Backup design that meets SAP certification and your retention rules
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
Deliverables
- RPO and RTO register agreed with business owners
- High availability and DR architecture document
- Configured HANA system replication, Pacemaker clusters and backup
- Failover, failback and restore runbooks
- DR test report with measured recovery times
- Remediation plan for any gaps found
Frequently asked
What is the difference between high availability and disaster recovery?
High availability keeps a system running through a local failure, such as a server or zone outage, usually with automatic failover in minutes. Disaster recovery restores service in another region after a larger event, and is usually a planned, manual switch with a longer recovery time.
Which HANA replication mode should we use?
Synchronous modes suit replication between zones in the same region, where latency is low and you need no data loss. Asynchronous mode suits longer distances between regions, accepting a small possible data loss in return for no impact on production performance.
Is there a cloud region in Sri Lanka?
No. AWS, Microsoft Azure and Google Cloud do not have a region in Sri Lanka today. Sri Lankan organisations usually place SAP in an Indian region such as Mumbai or in Singapore, and choose a DR region with data protection rules and latency in mind.
Do we still need backups if we have HANA system replication?
Yes. Replication copies every change, including accidental deletions and corruption, to the secondary. Backups give you a point in time to go back to, which replication cannot do.
How often should we test DR?
We recommend at least one full DR test a year for production SAP, plus regular restore tests of backups. Tests should also follow any major change to the landscape.
Often paired with this
Plan your move with people who know SAP.
One working session with our cloud and SAP architects. You leave with the options, the risks and a first plan.
- Your landscape reviewed
- The right cloud and region
- A first roadmap
The Rodwell Relay is our shorthand for looking after the details nobody sees in High Availability, DR & Backup.
AWS, Microsoft Azure, Google Cloud and SAP are trademarks of their respective owners.