Domain 2.3 of the PAS-C01 exam specifically targets your ability to perform system refresh, cloning, and copy processes for SAP landscapes on AWS efficiently. These processes are the backbone of keeping your SAP environment stable while allowing developers to test new features without breaking the live system that runs your business. Mastering this concept helps you save money, reduce downtime, and pass a critical exam objective.
Jump to a section
A simple way to picture SAP System Refresh and Cloning on AWS
Have you ever moved house and decided to give your old living room furniture a fresh coat of paint before placing it in the new home? That process of moving your belongings, updating them, and setting them up in a new location is a perfect parallel to SAP system refresh and cloning on AWS.
Imagine you own a successful bakery with a secret recipe book that lists every ingredient, oven temperature, and shelf position. One day, you decide to open a second bakery in a different town. You don't want to start from scratch, so you photocopy your entire recipe book. That photocopy is a 'clone' of your original system. But you also want your first bakery to have the latest seasonal specials, so you take the photocopy, add the new recipes, and then replace the old book with the updated one. That replacement is a 'system refresh'.
On AWS, your recipe book is your SAP system — a collection of applications, databases, and configurations. Cloning means creating an exact copy of that system, often for testing or training purposes, without touching the original. System refresh means overwriting a target system (like a quality-assurance copy) with data from a source system (like your live production system), but keeping the target's technical settings intact, much like keeping your bakery's ovens but updating the recipes. AWS provides the tools — think of them as moving trucks and painters — to make this fast, safe, and cost-effective. Without these techniques, you would have to rebuild everything manually, which is like handwriting a thousand-page cookbook from memory.
To understand SAP system refresh and cloning, first you need to understand what an SAP landscape is. An SAP landscape is a set of interconnected SAP systems that work together to support different stages of the software lifecycle. The most common landscape has three tiers: development (DEV), quality assurance (QA), and production (PROD). Developers write and test code in DEV. QA is where you verify that changes work correctly without harming real business operations. PROD is the live system that your company uses every day to run payroll, manage inventory, or process orders.
A 'system clone' is an exact copy of an entire SAP system, including the application, database, operating system, and all configurations. It is used when you need a completely independent system for a specific purpose, like training new staff or testing a major upgrade. The clone has its own identity on the network, its own IP address, and its own server instance. It does not share anything with the original system after the copy is made.
A 'system refresh' is different. It takes data from a source system (usually PROD) and copies it over to a target system (usually QA or a training system). However, the target system keeps its own technical settings, such as its name, network address, and certain configuration parameters. Think of it like updating the furniture in your guest bedroom to match your master bedroom, but keeping the room's layout and door location the same. System refreshes are critical because QA systems need to work with realistic data to catch bugs before they reach PROD.
On AWS, these processes are managed using several services and features:
Amazon EC2 (Elastic Compute Cloud): This is the virtual server that runs your SAP application and database. Cloning or refreshing involves creating new EC2 instances or attaching existing ones to different data volumes.
Amazon EBS (Elastic Block Store): This is the storage volume that holds your SAP data, like the hard drive in a computer. Snapshots of EBS volumes are used to create copies of data quickly.
AWS Backup: A managed service that can automate the creation of full system backups, which can then be used for clones or refreshes.
AWS Launch Wizard for SAP: This tool simplifies deploying SAP systems by automatically configuring EC2, EBS, and networking. When cloning, you can use it to quickly spin up a new environment based on the source system's architecture.
The process of a system clone on AWS typically follows these steps:
Stop the source SAP system to ensure data consistency. You cannot copy a database while it is being written to, or you will get a corrupted copy — like trying to photograph a book while someone is flipping the pages.
Take a snapshot of the source EBS volumes. This is a point-in-time copy stored in Amazon S3 (Simple Storage Service).
Create new EBS volumes from those snapshots.
Launch new EC2 instances and attach the new volumes.
Restore the SAP system on the new instances, changing the system ID (SID) to avoid conflicts on the network.
Start the cloned system.
A system refresh follows a similar pattern but is more targeted:
Back up the target system (QA) in case something goes wrong.
Stop both the source (PROD) and target (QA) systems.
Restore the source's data onto the target's database using AWS services like Amazon RDS (Relational Database Service) for SAP HANA or manual database restore techniques.
Update the target system's configuration to reflect the new data, like changing passwords or client settings.
Start the target system.
Why does anyone go through this trouble? Because without system refresh and cloning, you would have to manually create test data or risk breaking your live system every time you want to try a new configuration. It saves time, reduces errors, and keeps your business running smoothly. For the PAS-C01 exam, you need to know which AWS services to use for each step, how to minimise downtime, and how to handle the unique requirements of SAP systems, such as licensing and system IDs.
Plan and Notify Stakeholders
You must choose a maintenance window with low business impact, typically during weekends or overnight. Notify all teams that rely on the target system (e.g., QA testers) that it will be unavailable. This step prevents confusion and data loss.
Back Up the Target System
Before overwriting the target system, take a full backup using AWS Backup or EBS snapshots. This is your rollback plan — if the refresh fails or corrupts data, you can restore the target to its previous state quickly.
Stop the Source and Target Systems
Shut down the SAP application and database on both the source (e.g., PROD) and target (e.g., QA) systems. This ensures no data is being written during the snapshot, which prevents database corruption. On AWS, this means stopping EC2 instances.
Take a Database Snapshot of the Source
Create a point-in-time snapshot of the source database volumes using EBS snapshots or Amazon RDS snapshots (for SAP HANA). This captures the exact state of the data at that moment, which you will later restore onto the target.
Restore the Snapshot onto the Target and Update Configuration
Restore the snapshot onto the target system's storage. Then use SAP tools to update the system ID, hostname, user passwords, and any integration points (like RFC destinations) so the target system works as an independent environment. This step is critical to avoid network conflicts.
Start the Target System and Validate
Power on the target EC2 instances and start the SAP services. Run validation scripts to compare key data sets with the source system (before it was restarted). Verify that transactions, reports, and user logins work correctly.
Start the Source System and Monitor
After confirming the target is operational, restart the source system. Monitor both systems using Amazon CloudWatch to ensure they are performing normally. Document the refresh window for compliance and future planning.
A global retailer uses SAP to manage its inventory across 500 stores. The company has a typical three-system landscape: DEV for developers, QA for testing, and PROD for live operations. The QA team needs to test a new feature that calculates dynamic pricing based on weather data. To be sure the feature works correctly, they need data that reflects real sales, not made-up numbers. They decide to perform a system refresh from PROD to QA.
Here is what the IT professional, Maria, actually does step by step:
Plan the refresh window: Maria checks the company's calendar and picks a Sunday morning at 2:00 AM when store traffic is lowest. She sends a notification to all stakeholders saying the QA system will be unavailable for 6 hours.
Back up the current QA system: Before overwriting QA, Maria uses AWS Backup to create a full snapshot of the QA EBS volumes. This is her safety net — if the refresh fails, she can restore QA to its old state.
Stop the source (PROD) system: Maria places the PROD SAP system into 'shutdown mode' using the SAP management console and stops the EC2 instances. This takes about 15 minutes because the system must flush all pending transactions to the database.
Take a database snapshot: Using Amazon RDS for SAP HANA, Maria initiates a manual snapshot. This captures the entire database at a single point in time, ensuring no data is half-written.
Restore the snapshot on the QA system: Maria creates a new database instance for QA from the snapshot. She configures it with the same instance type and storage as QA had before, but keeps the QA system's original security groups and network settings.
Update system IDs and configurations: Because QA has a different system ID (SID) than PROD, Maria uses SAP tools to change the SID in the restored database. She also updates the hostname and IP addresses to match QA's existing network setup.
Start the target (QA) system: Maria powers on the QA EC2 instances and starts the SAP services. She runs a quick test — logging into QA and checking that the inventory data matches PROD's data from the moment of the snapshot.
Start the source (PROD) system: Now that QA is up, Maria restarts the PROD system. She must do this as quickly as possible because the store systems rely on PROD to process transactions.
Post-refresh validation: Maria runs a set of automated scripts that compare a few thousand records across PROD and QA to ensure the copy was complete.
The entire operation takes 5 hours, and the company loses no revenue because the refresh happened during low-traffic hours. Maria uses:
AWS Launch Wizard for SAP to automate the EC2 and database configuration.
AWS Systems Manager to run the post-refresh validation scripts.
Amazon CloudWatch to monitor CPU and memory usage during the process.
For cloning, a different scenario: the training team wants a dedicated system for a two-day workshop. Maria creates a clone of the QA system, which already has realistic data. She uses the same snapshot process but launches completely new EC2 instances with a unique SID. After the workshop, she deletes those instances to save costs. This cloning approach costs only a few dollars per hour — far cheaper than maintaining a permanently separate training server.
The PAS-C01 exam tests Domain 2.3 through scenario-based multiple-choice questions that require you to choose the most cost-effective, secure, and low-downtime approach for system refresh or cloning. Expect questions that present a business requirement (e.g., 'A company needs to refresh its QA system from PROD with minimal downtime. What should they do?') and then list four AWS solutions with varying levels of complexity.
Key exam topics you must master:
Snapshot vs. backup: The exam loves to ask when to use EBS snapshots compared to AWS Backup. Remember: EBS snapshots are faster for cloning entire volumes, while AWS Backup provides centralised policy management for long-term retention.
System ID (SID) management: Questions often present a scenario where a clone is created but the target system has a conflicting SID on the network. The correct answer will involve changing the SID using SAP tools before starting the system.
Downtime minimisation: The exam expects you to know that you must stop the source system for a consistent snapshot (cold backup) or use database-specific backup modes (hot backup) that allow partial availability. For SAP HANA, the use of multi-region replication can reduce downtime during refresh.
Licensing implications: SAP licensing is based on the system ID and the number of users. Cloning a system creates a new license requirement. The exam may ask about verifying that you have sufficient licenses before starting a clone.
Post-refresh tasks: A common trap is forgetting the cleanup steps — updating user passwords, disabling background jobs, and reconfiguring integrations. The exam might list a sequence of steps and ask which one is missing.
Trap patterns to watch for:
Presenting an answer that uses Amazon S3 directly for database files — this is wrong because SAP databases require block storage (EBS), not object storage (S3).
Suggesting that a clone and refresh are the same thing — they are not, and the exam will ask you to choose the right process for a given outcome.
Offering AWS Data Pipeline or AWS Snowball as a solution for a routine refresh — these are specialised tools for large data migrations, not everyday refresh tasks.
Ignoring the need to change the system ID after a clone — the exam expects you to select the option that includes 'run SAP post-copy automation'.
Key definitions to memorise:
Cold backup: System fully stopped before snapshot. Best for consistency, worst for downtime.
Hot backup: System remains partially available during backup. Used for 24/7 environments with SAP HANA's backup tools.
SID (System ID): A unique three-character identifier for each SAP system. Two systems with the same SID on the same network will cause conflicts.
Landscape: The collection of SAP systems (DEV, QA, PROD, sandbox, training) in an organisation.
AWS Launch Wizard for SAP: A deployment service that automates provisioning of EC2, EBS, and networking for SAP, reducing manual errors during refreshes.
A system clone creates a completely independent SAP system with a new system ID, while a system refresh overwrites data on an existing target system but preserves its technical identity.
To perform a consistent refresh or clone, you must stop the source SAP system or use a supported hot backup mode before taking a snapshot of the database volumes.
EBS snapshots are the recommended method for creating point-in-time copies of SAP data on AWS because they are fast and incremental.
After a clone, you must run SAP post-copy automation to change the system ID, hostname, and network configuration to match the new environment.
The PAS-C01 exam frequently tests the distinction between cold backups (system stopped) and hot backups (system partially available) for SAP systems on AWS.
A well-planned system refresh can reuse existing EC2 instances and EBS volumes, significantly reducing cost compared to building a new QA system from scratch.
These come up on the exam all the time. Here's how to tell them apart.
System Clone
Creates a brand-new, independent SAP system with a new SID.
Requires new EC2 instances and EBS volumes, increasing cost.
Used for training, sandbox, or long-term testing environments.
System Refresh
Overwrites data on an existing target system, keeping its original SID.
Reuses existing EC2 instances and storage, saving cost and time.
Used for updating QA or staging systems with current production data.
EBS Snapshot
Point-in-time copy of a single EBS volume, ideal for fast refreshes.
Manual process per volume, does not centralise policy management.
Best for cloning because it is faster for large database volumes.
AWS Backup
Centralised service that automates backup policies across multiple resources.
Can manage snapshots and full system backups with retention rules.
Best for long-term backup compliance, not for fast refreshes.
Cold Backup (System Stopped)
Source SAP system is fully stopped before snapshot.
Highest data consistency but longest downtime (30–60 minutes).
Simplest approach for refreshes on non-critical systems.
Hot Backup (System Partially Available)
Source system remains partially available using SAP HANA backup tools.
Writes are briefly frozen but users may experience a short pause.
Required for 24/7 environments but adds complexity to the refresh process.
Mistake
A system clone and a system refresh are the same thing with different names.
Correct
A clone creates an entirely independent copy with its own identity, while a refresh overwrites data on an existing system but keeps its technical identity (SID, hostname).
The terms sound similar, and both involve copying data, so beginners assume they are interchangeable. The exam specifically tests the distinction.
Mistake
You can refresh a QA system from PROD without stopping either system if you use AWS snapshots.
Correct
To get a consistent database copy, you must stop the source system (or use a hot backup mode that still freezes write operations momentarily). Snapshots taken during writes are corrupt.
People assume cloud snapshots are 'instant' and 'always consistent' because they work well for files. Databases have active transactions that require a quiet moment to capture.
Mistake
After a system refresh, the QA system can immediately start processing transactions without any manual steps.
Correct
You must update system-specific configurations like user passwords, background job schedules, and network integrations because the copied data still references the old system's environment.
Beginners think data is self-contained. In reality, SAP systems have many pointers (like RFC destinations) that break if not updated after a refresh.
Mistake
AWS Backup is the fastest way to refresh a system because it is a managed service.
Correct
AWS Backup is slower for refreshes because it creates a separate backup copy and then restores. Direct EBS snapshots are faster for point-in-time copies used in refreshes and clones.
Managed services sound better ('AWS handles it'), but speed is not their strength. The exam tests your knowledge of which tool is appropriate for the task.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, but you must change the system ID (SID) and update sensitive data like user passwords to avoid conflicts on the network and to comply with licensing. A clone is a separate system, so testing on it does not affect PROD.
It depends on the database size. A typical refresh of a 500 GB SAP HANA database can take 2-4 hours, including the snapshot, restore, and configuration steps. AWS services like EBS snapshots are incremental, so subsequent refreshes are faster.
Yes, for a consistent snapshot you must stop the PROD system (cold backup) or use SAP HANA's backup tools (hot backup) that still pause writes momentarily. Without stopping, you risk database corruption.
No, AWS DataSync is designed for transferring large files between on-premises and AWS, not for database-level refreshes. Use EBS snapshots or Amazon RDS snapshots for SAP system refreshes.
The old data is completely overwritten by the new data from the source. That is why you back up the target system first — if you later need something from the old QA data, you can restore from that backup.
Not necessarily. You can run DEV, QA, and PROD in the same AWS account using different VPCs (Virtual Private Clouds) or subnets, but many companies use separate accounts for better security and cost tracking. The exam expects you to know that separate accounts are a best practice for isolation.
You've finished SAP System Refresh and Cloning on AWS. Continue through the PAS-C01 study guide to build a complete picture of the exam.
Done with this chapter?