Welcome to the automation hub of SAP Basis! There is hardly any task in large SAP infrastructures that consumes as much operational time as the regular System Refresh (the homogeneous system copy). Production test systems (QA/QAS) must be supplied with fresh data from production (PRD). The classic path: Take database backups, copy terabytes of data over the network, fire up R3load, and spend days on manual post-processing.
By mid-2025, this manual process is no longer justifiable in enterprise environments. The solution is the combination of SAP Landscape Management (LaMa) Enterprise Edition and cloud-native storage APIs on AWS. Today we analyze the architecture of a fully automated storage-based system copy that turns days into minutes.
The Architectural Paradigm: Block-Level Storage Snapshots
SAP LaMa acts as the central orchestrator. The key to the speed advantage lies in the fact that LaMa no longer works with the SAP software itself to copy data, but communicates directly with the infrastructure APIs of the cloud provider (AWS).
The architectural setup looks like this:
-
Quiesce the Database: LaMa freezes the productive S/4HANA database for a few fractions of a second (I/O is paused) to guarantee application consistency.
-
AWS API Call: Using the SAP LaMa AWS Adapter, the tool fires a native API call to AWS to create an EBS Snapshot (Elastic Block Store) of the HANA Data and Log volumes.
-
Un-Quiesce: Production immediately resumes normal operation.
-
Volume Clone & Attach: AWS creates new EBS volumes (e.g., io2 or gp3) from the snapshot within seconds. LaMa orchestrates the mounting (attaching) of these new disks to the EC2 instance of the QA system.
Due to this block-level approach, it completely doesn't matter whether the database is 500 GB or 15 terabytes in size – the pure "copy" of the data takes only a few moments.
Post-Copy Automation (PCA): The End of Manual Basis Scripts
Copying the data is only half the battle. What happens to the logical system names, the RFC connections, and the user authorizations? When the QA system starts, it still believes it is the productive system (same SID).
This is where SAP LaMa's Post-Copy Automation (PCA) steps in:
-
System Rename: LaMa fully automatically changes the System ID (SID) and the schema names at the database level via the integrated Software Provisioning Manager (SWPM).
-
BDLS Run: The logical system names are adjusted in all tables of the SAP database.
-
Security Cleanup: Certificates (
STRUST), SecStore entries, and RFC destinations (SM59) pointing to external bank or HR interfaces are automatically deleted or rewritten so that the QA system does not accidentally send real-time emails to real customers.
📢 SAP & AWS ARCHITECTURE NEWS TICKER (As of: June 2025) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔹 EBS io2 Block Express Integration: AWS and SAP LaMa now natively support the provisioning of io2 Block Express volumes for system copies. This means sub-millisecond latencies straight out-of-the-box for the freshly cloned QA systems, exactly as in production. 🔹 Automatic Instance Type Switch: A new feature allows a "downsize" of the EC2 instance during the system copy in LaMa. This means the 12TB production system (x1e.32xlarge) can be cloned onto a significantly cheaper R5 instance for a brief development test (provided the utilized RAM allows it).
Conclusion for Enterprise Architects
SAP Landscape Management (LaMa) in combination with AWS EBS snapshots is the absolute endgame for SAP Basis operations. It decouples the data size from the duration of the system copy. For us IT architects and Basis admins, this means: Routine tasks are automated at the push of a button ("One-Click Refresh"). This reduces human errors during post-processing to zero and frees up massive resources to focus on strategic topics like Clean Core and cloud security.