What happens when your company’s entire SAP system — the heart of accounting, inventory, and payroll — suddenly stops working because of a server crash, a human error, or a hurricane? This chapter explains how to protect that system with backups and disaster recovery so it can be restored quickly, anywhere, with minimal data loss. For the PAS-C01 exam, you must understand exactly which AWS services to combine and how the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) drive every design decision.
Jump to a section
A simple way to picture Backup, Recovery, and Disaster Recovery for SAP
Your grandmother’s handwritten cookbook sits on your kitchen counter. It contains the only copy of the family’s secret pasta sauce recipe. That cookbook is your SAP system, full of irreplaceable business data and custom configurations. Every week you photograph every page of that cookbook and store the photos in a fireproof safe in your living room. Those photos are your EBS snapshots — point-in-time copies of a single volume kept in the same location. Once a month you also photocopy the entire cookbook and mail that photocopy to your cousin in another state, storing the original in a bank vault. That photocopy is your AWS Backup vault copy to a different AWS Region, protecting against city-wide disasters. Your cousin’s house is your Disaster Recovery region. If your kitchen catches fire, you lose the original cookbook, but you have the photos (snapshots) to reconstruct the recipe. If the entire city floods, you still have the photocopy (cross-region backup) at your cousin’s house. The crucial difference: a photo is fast to take but only protects against a small fire (single Availability Zone failure), while the photocopy in another state is slower to create but survives a city-wide catastrophe (Region failure). You also practise the restoration process every quarter by actually cooking from the photocopy — that’s a DR drill to ensure your backups are usable.
An SAP system running on AWS is a collection of virtual servers (Amazon EC2 instances) with attached storage volumes (Amazon EBS volumes). These volumes hold the operating system, the SAP application binaries, and most critically, the database files that contain all business transactions, customer records, and financial data. If a volume fails, data is corrupted, or someone accidentally deletes a critical file, you need a copy to restore from. That copy is a backup.
Backups come in two fundamental types. The first is an EBS snapshot. An EBS snapshot is a point-in-time copy of an entire EBS volume. It is stored in Amazon S3 (Simple Storage Service) behind the scenes — you never see the S3 bucket itself. Snapshots are incremental: the first snapshot copies the entire volume, but subsequent snapshots only copy the blocks that changed since the last snapshot. This saves storage costs and speeds up creation. Snapshots are created per volume, and a typical SAP system may have separate volumes for the database, log files, and application files.
The second type is a backup created by AWS Backup. AWS Backup is a managed service that lets you centralise and automate backups across multiple AWS services, including EBS volumes, RDS databases, and even on-premises servers connected via AWS Storage Gateway. With AWS Backup you define a backup plan (daily snapshots, weekly vault copies) and it runs on schedule without any script. You store backups in a backup vault, which is a logical container that can be encrypted and locked to prevent deletion. AWS Backup can also copy backups to another AWS Region automatically, giving you cross-region protection.
Now comes Disaster Recovery (DR). Backup is about restoring a file or volume after a small incident. Disaster Recovery is about surviving a catastrophic event — a whole AWS Region becoming unavailable because of a natural disaster, a power grid failure, or a major software bug. DR requires a complete, separate copy of your SAP infrastructure in another AWS Region, and a process to switch traffic to that copy. The key metrics are:
Recovery Point Objective (RPO): How much data can you afford to lose measured in time? For example, an RPO of 15 minutes means you can lose at most 15 minutes of transactions.
Recovery Time Objective (RTO): How fast must the system be running again? An RTO of 4 hours means you have four hours to get SAP fully operational after the disaster declaration.
There are four common DR strategies for SAP, listed from cheapest to most expensive:
Backup and Restore: You regularly back up data to another Region. When disaster strikes, you provision new servers, restore the latest backup, and reconfigure networking. RTO can be hours or days.
Pilot Light: You keep a minimal set of core services (like a small database server) running in the DR region. The rest of the infrastructure — application servers, load balancers — stays turned off. Upon disaster, you scale up the database and launch the application servers from pre-prepared Amazon Machine Images (AMIs). RTO is typically hours.
Warm Standby: You run a scaled-down but fully functional copy of the production SAP system in the DR region. The database is mirrored using SAP HANA System Replication or similar technology, so data loss is near zero. On disaster declaration, you scale up the DR servers and redirect users. RTO is minutes to an hour.
Multi-Region Active-Active: Both regions serve user traffic simultaneously. This is the most complex and expensive strategy, and rarely used for SAP because SAP systems are stateful and hard to run active-active without custom application logic. The exam usually focuses on Warm Standby and Pilot Light.
To execute these strategies, SAP on AWS relies on database-specific replication. For SAP HANA, you use SAP HANA System Replication (HSR) with AWS global infrastructure. For SAP AnyDB (like Oracle or SQL Server), you use native database replication features, often combined with AWS services like AWS Database Migration Service (DMS) or Storage Gateway. AWS also offers Elastic Disaster Recovery (AWS DRS) — a service that continuously replicates your entire server (including the operating system and database) to a staging area in another Region, allowing rapid failover.
Every DR plan must be tested annually at minimum. A test involves simulating a disaster (e.g., turning off the production region) and verifying that the DR system can handle live user load. Without testing, you might discover that your backups are corrupted, the DR servers are misconfigured, or network routes don't work. The AWS Well-Architected Framework includes the Reliability Pillar, which specifically requires documented, tested DR plans.
Finally, security is critical. Backups must be encrypted. AWS Backup vaults support AWS Key Management Service (KMS) for encryption. Backup vaults can also have a vault lock policy — once enabled, it prevents anyone (even AWS administrators) from deleting backups for a specified period. This protects against ransomware attacks where an attacker tries to delete all backups.
Assess RPO and RTO Requirements
Before any technical design, you must know how much data loss is acceptable (RPO) and how fast the system must recover (RTO). For example, an RPO of 15 minutes means you need near-continuous replication; an RTO of 2 hours means you cannot use Backup and Restore from cold storage. This step determines every subsequent choice.
Choose Backup Strategy for Volumes and Databases
Based on RPO, decide between scheduled EBS snapshots or log-based continuous backups. For RPOs below 1 hour, use database-native log shipping (like HANA log backups every 15 minutes) combined with automatic EBS snapshots via AWS Backup. For longer RPOs, daily snapshots may suffice.
Configure AWS Backup Plan with Cross-Region Copy
Create a backup plan in AWS Backup that specifies the frequency (e.g., every 6 hours) and retention (e.g., 30 days). Enable cross-region copy to a secondary AWS Region to protect against Region failure. Also configure vault lock to prevent deletion for a defined period.
Design Disaster Recovery Topology in Secondary Region
Select a DR strategy: Pilot Light (minimal infrastructure, manual scale-up), Warm Standby (smaller running copy), or Multi-Region. For SAP HANA with low RPO, set up HANA System Replication to the DR region. For SAP AnyDB, set up native database replication (e.g., Oracle Data Guard) or use AWS DRS to replicate the entire server.
Automate Failover with AWS Systems Manager and Route 53
Create a runbook that automates the steps to launch or scale up DR servers, attach the replicated database, update DNS (Route 53) to redirect traffic, and start application services. Use AWS Systems Manager Automation documents to execute these steps with one click or automatically on a health check failure.
Test the DR Plan Regularly
Schedule quarterly DR drills. During each drill, actually failover to the DR region, run business transactions, verify data consistency, and then fail back. Document any issues (like missing permissions or insufficient disk space) and fix them. Without testing, you cannot guarantee the plan works.
A large manufacturing company, let’s call them ManufacCorp, runs SAP S/4HANA on AWS. Their SAP system processes 50,000 purchase orders daily. The IT team consists of five people, none of whom are backup specialists. They have been told by auditors they must meet an RPO of 15 minutes and an RTO of 2 hours for any disaster that affects the primary AWS Region (eu-west-1, Ireland).
The team starts by enabling AWS Backup. They create a backup plan that takes an EBS snapshot of the SAP HANA database volume every 15 minutes using the HANA database’s log backup feature combined with manual snapshot triggers via a Lambda function. They also take daily snapshots of all application server volumes. These snapshots are stored in an AWS Backup vault in the Ireland region.
Next, they configure cross-region copy. AWS Backup automatically copies every snapshot to a backup vault in the secondary region (eu-central-1, Frankfurt). This gives them protection if Ireland Region fails entirely.
For Disaster Recovery, they choose a Warm Standby strategy. In Frankfurt, they keep a smaller EC2 instance running the SAP HANA database with a copy of the production data, synchronised via SAP HANA System Replication in synchronous mode. This means every transaction on the primary database is also written to the Frankfurt database before the transaction is considered committed. RPO is effectively zero — no data loss.
The application servers (SAP Web Dispatchers, ABAP application servers) are not running in Frankfurt — they are in a turned-off state. But the team has pre-built Amazon Machine Images (AMIs) of all application servers, stored in the Frankfurt region. When a disaster is declared, the team follows a runbook:
Step 1: Use AWS Systems Manager Automation to launch new EC2 instances from the AMIs (5 minutes).
Step 2: Attach the existing Frankfurt database instance (already running) to these new application servers (2 minutes).
Step 3: Update Route 53 DNS records to point the SAP URL to the Frankfurt load balancer (1 minute).
Step 4: Run a custom script to notify users and restart batch jobs (5 minutes).
Total RTO from disaster declaration to full operation: about 15 minutes. They meet their 2-hour target comfortably.
Once a quarter, the team runs a DR drill. They actually switch user traffic to Frankfurt for 30 minutes, then switch back. During this drill, they discover that a database log file has filled up the disk in Frankfurt, causing a failure. They fix the issue by adding an automated alert for disk space in the DR region. Without the drill, this issue would have caused the real failover to fail.
The entire backup and DR setup costs about 40% of their production infrastructure cost, which the CFO accepted after seeing the risk analysis of potential revenue loss during a three-day outage.
The PAS-C01 exam tests your ability to design backup and DR solutions that meet specific RPO and RTO requirements. You will see scenario-based questions where you must choose the correct combination of services. The exam loves to test the following concepts:
RPO and RTO definitions: You will be given a scenario with stated RPO (e.g., 15 minutes) and RTO (e.g., 1 hour). The correct answer must achieve both. For example, backup and restore only satisfies RTO if the data volume is small and you have pre-provisioned compute. Warm Standby with HANA System Replication is the standard answer for sub-1-hour RTO and near-zero RPO.
AWS Backup vs. EBS Snapshots: AWS Backup is a managed service. EBS Snapshots are a native feature. AWS Backup can automate snapshots, copy across regions, and enforce retention policies. The exam will ask which service to use for automated, centralised backup management. AWS Backup is almost always the answer when the question mentions 'centralised backup management' or 'retention policy'.
Vault Lock: Questions about protecting backups from deletion (especially ransomware) will point to Backup Vault Lock. If a question says 'prevent accidental or malicious deletion of backups for 7 days', the answer is Vault Lock with a governance mode.
Cross-Region vs. Cross-Account Backup: Cross-region copies protect against region failure. Cross-account copies protect against account compromise. The exam may ask: 'An organisation wants to protect against an AWS account hijack — what should they do?' The answer is to copy backups to another AWS account using AWS Backup across accounts.
Database-Specific Replication: For SAP HANA, the answer is SAP HANA System Replication (HSR). For SAP AnyDB (Oracle, SQL Server), the answer is native database replication (Oracle Data Guard, SQL Server Always On) plus AWS Storage Gateway or AWS DMS. Do not choose generic EC2-based replication for database replication.
AWS Elastic Disaster Recovery (AWS DRS): This service replicates entire servers continuously. It is simpler than manual Pilot Light setups. Exam questions may ask: 'Which service provides continuous block-level replication of entire EC2 instances to another Region?' Answer: AWS Elastic Disaster Recovery.
Common traps:
Trap: Choosing 'take manual EBS snapshots every hour' when the RPO is 15 minutes. Manual snapshots cannot achieve sub-15-minute RPO without automation.
Trap: Picking 'Multi-Region Active-Active' for SAP when the question doesn't mention custom application code. SAP typically runs active-passive, not active-active.
Trap: Ignoring the cost implication. The exam sometimes asks 'which strategy is most cost-effective for this RPO/RTO?' Backup and Restore is cheapest, Warm Standby is expensive.
Trap: Thinking cross-region copy is available without AWS Backup. EBS snapshots can be copied manually across regions using the CopySnapshot API, but the exam prefers AWS Backup for automation.
Definitions to memorise:
Recovery Point Objective (RPO): maximum acceptable data loss measured in time.
Recovery Time Objective (RTO): maximum acceptable downtime after a disaster.
Backup Vault: logical container in AWS Backup.
Vault Lock: immutability feature for backup vaults.
SAP HANA System Replication: built-in HANA feature for synchronising databases.
Pilot Light: minimal DR infrastructure that can be scaled up.
Warm Standby: scaled-down but fully functional DR environment.
Recovery Point Objective (RPO) and Recovery Time Objective (RTO) are the two metrics that drive every backup and DR design decision on the PAS-C01 exam.
AWS Backup is the centralised managed service for automating backups across EBS, RDS, and other AWS services, and it supports cross-region and cross-account copy.
EBS snapshots are point-in-time, incremental copies of a single volume, but they are regional and must be copied to another Region to survive a Region failure.
For SAP HANA, warm standby with HANA System Replication (synchronous mode) is the standard DR pattern for sub-15-minute RPO and sub-1-hour RTO.
Vault Lock in AWS Backup provides immutability: once enabled, no one can delete or overwrite backups, protecting against ransomware and accidental deletion.
DR testing is not optional — you must test your plan regularly (at least annually) to ensure backups are restorable and the failover process works.
The cheapest DR strategy (Backup and Restore) usually fails the RTO requirement, while the most expensive (Active-Active) is rarely used for SAP S/4HANA.
AWS Elastic Disaster Recovery (AWS DRS) provides continuous block-level replication of entire servers to another Region, simplifying Pilot Light and Warm Standby setups.
These come up on the exam all the time. Here's how to tell them apart.
EBS Snapshot
Manual or script-based, per-volume backup
Stored in same AWS Region by default
No central policy management; no vault lock
AWS Backup
Managed service with automated schedules and lifecycle rules
Can copy backups to another Region automatically
Centralised policy, cross-account backup, vault lock for immutability
Pilot Light
Minimal infrastructure running in DR region (e.g., small database with replicas)
Application servers are turned off, launched on failover
RTO typically hours; RPO varies based on replication method
Warm Standby
Full but scaled-down infrastructure running in DR region
Application servers are running at reduced capacity, scaled up on failover
RTO typically minutes to an hour; RPO near zero with synchronous replication
SAP HANA System Replication
Database-level replication; only data and log changes
Requires SAP HANA license and configuration
Synchronous mode gives zero data loss; asynchronous may lag
AWS Elastic Disaster Recovery (AWS DRS)
Server-level replication; entire EC2 instance, including OS and all applications
No application-specific license needed; works with any OS
Continuous block-level replication; RPO typically seconds to minutes
Cross-Region Backup Copy
Copies backup to another AWS Region
Protects against Region failure
Same AWS account ownership but different geographic location
Cross-Account Backup Copy
Copies backup to another AWS account
Protects against account compromise (think hijacked credentials)
Different account ownership; requires AWS Backup with cross-account management
Mistake
EBS snapshots alone are sufficient for disaster recovery across AWS Regions.
Correct
EBS snapshots are stored in the same Region as the volume by default. To survive a Region failure, you must copy snapshots to another Region using AWS Backup or manual CopySnapshot actions.
Beginners confuse Availability Zone (AZ) failure with Region failure. EBS snapshots protect against a single server or AZ failure, but an entire Region outage requires cross-region copies.
Mistake
AWS Backup is just a UI wrapper around EBS snapshots and adds no new functionality.
Correct
AWS Backup offers centralised policy management, cross-region copy, cross-account backup, vault lock for immutability, and native lifecycle rules (automatic deletion of old backups). These capabilities don't exist when manually managing EBS snapshots individually.
If you only know the basic snapshot feature, you might assume a managed service is a simple overlay. The exam tests the unique benefits of AWS Backup.
Mistake
A single EBS snapshot is enough to restore a multi-volume SAP system like SAP HANA.
Correct
SAP HANA uses multiple volumes: data, log, shared, and backup. Restoring requires all volumes to be consistent at the same point in time. You must use crash-consistent snapshots (all volumes snapped simultaneously) or use HANA-specific backup tools. A single snapshot of only the data volume will leave the database corrupt.
People think of a database as a single file, but modern databases spread across multiple disks. The exam often tests consistency across volumes.
Mistake
Disaster Recovery testing is optional because you can trust AWS to keep your backups safe.
Correct
DR testing is mandatory in every well-architected SAP on AWS design. The AWS Well-Architected Framework and the exam both require you to test your DR plan at least annually. Backups can be corrupt, permissions can change, and networks can be misconfigured — testing catches these.
Newcomers to IT assume that 'backed up' equals 'safe'. The exam explicitly tests whether you understand the need for validation through testing.
Mistake
Vault Lock prevents all deletion of backups, so you never have to manage storage costs.
Correct
Vault Lock prevents deletion, but backups still accumulate and incur storage costs. You must set lifecycle policies (e.g., delete backups older than 90 days) before locking the vault, because after locking you cannot delete them or change the retention rule.
Security features like immutability are attractive, but students forget the operational cost impact. The exam tests your ability to balance security with cost management.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An EBS snapshot is a point-in-time backup of a single EBS volume, created manually or via a script. AWS Backup is a managed service that can automate snapshots across multiple volumes, databases, and services, and it adds features like centralised policy management, cross-region copy, vault locking, and lifecycle rules.
By default, EBS snapshots are stored in the Region where the volume lives. You can manually copy a snapshot to another Region using the CopySnapshot API or the AWS Management Console, but for automated cross-region DR, you should use AWS Backup with cross-region copy enabled.
A backup vault is a logical container where AWS Backup stores your backups. It can have encryption settings (using AWS KMS), IAM resource-based policies to control access, and a vault lock feature that makes backups immutable (cannot be deleted or overwritten) for a specified period.
For an RPO of 5 minutes, you need near-continuous replication. The best strategy is Warm Standby using SAP HANA System Replication in synchronous mode, which replicates every transaction to a database instance in the DR region. This gives you zero data loss (RPO = 0) and an RTO of minutes to an hour.
Use AWS Backup Vault Lock. When you enable vault lock in governance mode, backups cannot be deleted or overwritten for a retention period you define (e.g., 7 days). For stronger protection, use compliance mode, which locks the policy until the retention period expires, and even AWS administrators cannot delete the backups.
Yes, but they must be taken at the same point in time to ensure the database is consistent. You should use crash-consistent snapshots or multi-volume snapshots (a feature of AWS Backup) that snap all volumes of an EC2 instance simultaneously. Restoring from snapshots taken at different times will corrupt the database.
You've finished Backup, Recovery, and Disaster Recovery for SAP. Continue through the PAS-C01 study guide to build a complete picture of the exam.
Done with this chapter?