SAP system copy: step-by-step guide, homogeneous copy with SWPM and post-processing

What is an SAP system copy?

In a system copy, a target system is created from the database of a source system. The Software Provisioning Manager installs the instances of the target system from scratch and builds the database from a copy of the source database. The whole system is always transferred. Individual product instances or components can be neither selected nor excluded.

Typical reasons according to SAP: setting up systems for testing, training or standby, changing hardware or the operating system, restoring a system from a backup. In practice, refreshing QA and test systems from production is another.

The client copy is a different matter. It only transfers the client-specific data of one client; the repository and the other clients of the target system remain untouched. The transactions involved are explained in the article SAP client copy. It cannot replace the system copy: SAP explicitly does not support client transport as a method for a system copy.

Homogeneous and heterogeneous system copy

In a homogeneous system copy, the operating system and database stay the same, and the content of the database is transferred. If the operating system, the database or both change, SAP speaks of a heterogeneous system copy, also known as migration or OS/DB migration. Where the boundary lies in individual cases, for example when changing the Linux distribution, is covered by SAP Knowledge Base Article 2379836.

In S/4HANA, the database is always SAP HANA. For copies within an S/4HANA landscape, the homogeneous system copy is therefore the norm. The heterogeneous copy is a project in its own right: according to SAP, it should only be performed by certified consultants, and according to the guide, SWPM 2.0 does not support it.

Methods: backup/restore or export/import

SAP distinguishes two ways of transferring the database: database-specific, using the tools of the database vendor, or database-independent, using the SAP tools for export and import.

SWPM 2.0 is responsible for ABAP systems on SAP HANA 2.0 from S/4HANA 1809 and uses a HANA backup for the system copy. SWPM 1.0 covers older releases, other databases as well as Java and dual-stack systems (SAP Note 2568783).

For a consistent export with R3load, SAP recommends stopping the SAP system while the database keeps running. SWPM does not export objects outside the ABAP Dictionary. If SAP HANA is the source and the system is on AS ABAP 7.52, SAP rules out the database-independent method because the system uses HANA artefacts that R3load does not support.

Replacing only the database content. If the target system already exists, SWPM offers the option ‘Refresh Database Content’. It replaces the content of the database from a backup without reinstalling the instances. SAP recommends it for aligning the database content of existing, fully configured systems.

Preparing the system copy

A system copy with production data needs a plan. The SAP guide and practical experience give rise to these points:

• Timing and test run: Coordinate copies with production data with month-end and year-end closing. A test run shows how long backup, transfer and restore take, and therefore the downtime required.
• System ID: Every system needs its own unique SID. SAP Note 1979280 lists the reserved IDs.
• Version and platform: The HANA version in the target must be the same as or higher than in the source, and both platforms need the same byte order (endianness). Check the minimum kernel patch level for the support package level of the source.
• Disk and memory: The target needs disk space and main memory for the complete database, roughly the sizing of production.
• Licences: Plan a new SAP licence key and a HANA licence for the target. The key of the source is not valid in the target system.
• Source system: Clean up cancelled or open update requests in SM13, suspend the scheduling of released jobs with report BTCTRNS1 (SAP Note 37425) and avoid operation mode switches (SM63) during the copy. When copying from a running production system, suspending the jobs in the source is usually not wanted. In that case, suspend the jobs only in the target system, before background processes start there.
• Existing target system: Before overwriting, note down the logical system names of all clients (SCC4) and back up system-specific settings. What this includes is shown in the runbook for the QA refresh.
• Protect the backup: The backup contains all production data. SAP points out that it must be protected against unauthorised reading and modification throughout its entire life cycle, for example by encryption.

Step-by-step guide: homogeneous SAP system copy with HANA backup/restore and SWPM

For S/4HANA from 1809, SAP describes the procedure in the system copy guide for SWPM 2.0. In brief:

1. Provide the target database. Install SAP HANA in the target system, in the same or a higher version than the source.
2. Back up the source. Create a complete data backup of the source database, for example with SAP HANA Studio or Cockpit, to file or via Backint.
3. Transfer the backup. Copy all files of the backup to a directory that the target database can read.
4. Start SWPM. In the Software Provisioning Manager, select the system copy for the target system. On the database screen, select the homogeneous system copy using SAP HANA backup/recovery.
5. Specify schema and backup. Enter the schema names and passwords of the source as they are stored in the backup. Then specify the directory and prefix of the backup, or for Backint the database SID of the source. SWPM restores the database in the target.
6. Install the HANA licence. Because the backup comes from a different database, the target needs a new licence.
7. Post-processing. If you suspended the jobs in the source, release them again there with BTCTRNS2. In the target system, work through the checklist below.

With the ‘Refresh Database Content’ option, there is no need for a reinstallation. You stop the application servers of the target, leave the ASCS instance running and select the option for SAP HANA under the generic options in SWPM. The schema name in the target must match the one in the backup. SAP Note 1844468 describes the specifics of the homogeneous copy on SAP HANA.

How long does an SAP system copy take?

There is no fixed duration. The runtime depends above all on the size of the database and is made up of several parts:

• Backing up the source: The SAP HANA data backup runs while the system is in operation. How long it takes depends on the data volume and the backup target, i.e. file or Backint.
• Transfer: The backup files have to be where the target database can read them. The network and storage between the systems determine how long this takes.
• Restore in the target: SWPM restores the database from the backup. With the option “Refresh Database Content”, the instances do not have to be reinstalled.
• Post-processing: Transport management, RFC connections, jobs and users take time, as does the BDLS run across all tables. On top of that come transports that have to be imported again in the target.

The downtime mainly affects the target system: it is unavailable from the start of the restore until the end of post-processing. SAP recommends a test run to determine this downtime. It grows with every year of history in production.

Post-processing after the system copy: checklist

After the copy, the target system has the connections, jobs and settings of the source. Without post-processing, it may contact partner systems of production or send output to real recipients. The most important steps for the ABAP system according to the SAP guide:

• Licence: Install the new licence key in SLICENSE.
• Transport management: In SE06, run the post-installation processing for ‘Database copy or migration’, then set up the domain, transport parameters and transport routes in STMS. Reschedule the transport dispatcher in client 000 with report RDDNEWPP.
• Logical systems: If the SID has changed, convert the logical system names with BDLS. Check the client settings in SCC4.
• RFC and interfaces: Check RFC destinations in SM59, tRFC in SM58 and qRFC in SMQR. Redirect or delete connections to production, and adjust secondary database connections in DBCO.
• Jobs: Delete cancelled and finished jobs, adjust the jobs required in the target and only then release the suspended jobs with BTCTRNS2.
• Printing and output: Adjust printers and spool servers in SPAD, delete old spool requests (RSPO0041). Check email sending (SCOT) before messages reach real recipients.
• Profiles and operation modes: Empty tables TPFET and TPFHT, import profiles in RZ10, adjust operation modes (RZ04, SM63), logon groups (SMLG) and RFC server groups (RZ12).
• Security: Replace the PSEs in STRUST with new ones containing the data of the target system and check the secure storage in SECSTORE.
• Users: Review system users and authorisations (SU01). For a refresh, restore the backed-up users of the target system.
• File system: Check directories, NFS mounts, external commands (SM69) and logical file paths (FILE) that may point to production. Clarify access to the archive files of the source.
• Checks: Consistency check (SM28), system log (SM21), database (DB02) and servers (SM51).
• Data protection: Mask personal data before testers and developers get access. What matters here is explained in the article Personal data in SAP test systems.

For many of these steps, SAP offers ABAP Post-Copy Automation with predefined task lists in the ABAP task manager (STC01). According to the guide, it requires a licence for SAP Landscape Management Enterprise Edition. What needs to be done after a client copy is shown in the checklist in the basics article on client copy.

System copy or client copy?

The system copy is the right tool when a complete image is needed: for load and performance tests with the full data volume, for new systems with the status of production and for hardware or platform changes.

For the regular refresh of QA and test systems, it has drawbacks. It overwrites the development status in the target. Transports that are not yet in production have to be imported again afterwards. The target needs as much HANA memory as production, and BDLS has to search the entire database.

A client copy leaves the repository and other clients untouched, but with the standard tools it brings along the complete history. This is where the Data Refresh Operator comes in. It copies a time slice, for example the last 90 days, plus all dependent objects from earlier years, until it is verifiable that nothing is missing. DRO replaces logical system names during the import, before the data is written to the database. No subsequent BDLS run is needed.

–75%

HANA RAM in non-production

–60%

Storage and backup

Guideline values from reference scenarios. The actual effects depend on system size, history and refresh cycles. DRO runs on SAP S/4HANA from release 2023.

DRO replaces the client copy, not the system copy. For load and performance tests, new systems and platform changes, the system copy with SWPM remains the method of choice. The page System copy, client copy and time slice compared shows the three methods side by side. Why BDLS takes so long after a system copy is explained in the article BDLS after a system or client copy.

Frequently asked questions about the SAP system copy

Sources

• SAP Help: System Copy for SAP ABAP Systems Based on UNIX: SAP HANA 2.0 Database, Using Software Provisioning Manager 2.0 (PDF)
• SAP Help: System Copy for SAP Systems Based on the Application Server ABAP of SAP NetWeaver 7.3 EHP1 to 7.52 on Windows: SAP HANA Database, Software Provisioning Manager 1.0 (PDF)
• SAP Help: Processing After Installation of the CTS (transaction SE06)
• SAP Note 1844468: Homogeneous system copy on SAP HANA (SAP Support Portal, login required)
• SAP Note 2568783: Release Note for Software Provisioning Manager 2.0 (SAP Support Portal, login required)
• SAP Knowledge Base Article 2379836: Homogeneous or Heterogeneous system copy in case of minor OS change