SAP-Systemkopie: Anleitung, homogene Kopie mit SWPM und Nacharbeiten

Was ist eine SAP-Systemkopie?

Bei einer Systemkopie (englisch: System Copy) entsteht ein Zielsystem aus der Datenbank eines Quellsystems. Der Software Provisioning Manager installiert die Instanzen des Zielsystems neu und baut die Datenbank aus einer Kopie der Quelldatenbank auf. Übertragen wird immer das ganze System. Einzelne Produktinstanzen oder Komponenten lassen sich weder auswählen noch ausschließen.

Typische Anlässe laut SAP: Systeme für Test, Schulung oder Standby aufbauen, Hardware oder Betriebssystem wechseln, ein System aus einer Datensicherung wiederherstellen. In der Praxis kommt der Refresh von QS- und Testsystemen aus der Produktion hinzu.

Abzugrenzen ist die Mandantenkopie. Sie überträgt nur die mandantenabhängigen Daten eines Mandanten, Repository und andere Mandanten des Zielsystems bleiben unberührt. Die Transaktionen dafür erklärt der Artikel SAP-Mandantenkopie. Ersetzen kann sie die Systemkopie nicht: Den Mandantentransport unterstützt SAP ausdrücklich nicht als Methode für eine Systemkopie.

Homogene und heterogene Systemkopie

Bei der homogenen Systemkopie bleiben Betriebssystem und Datenbank gleich, übertragen wird der Inhalt der Datenbank. Wechseln Betriebssystem, Datenbank oder beides, spricht SAP von einer heterogenen Systemkopie, auch Migration oder OS/DB-Migration genannt. Wo die Grenze im Einzelfall liegt, etwa beim Wechsel der Linux-Distribution, behandelt der SAP-Knowledge-Base-Artikel 2379836.

Bei S/4HANA ist die Datenbank immer SAP HANA. Für Kopien innerhalb einer S/4HANA-Landschaft ist die homogene Systemkopie deshalb der Normalfall. Die heterogene Kopie ist ein eigenes Projekt: Laut SAP sollen sie nur zertifizierte Berater durchführen, und SWPM 2.0 unterstützt sie laut Leitfaden nicht.

Methoden: Backup/Restore oder Export/Import

SAP unterscheidet zwei Wege, die Datenbank zu übertragen: datenbankspezifisch mit den Werkzeugen des Datenbankherstellers oder datenbankunabhängig mit den SAP-Werkzeugen für Export und Import.

SWPM 2.0 ist für ABAP-Systeme auf SAP HANA 2.0 ab S/4HANA 1809 zuständig und arbeitet bei der Systemkopie mit einer HANA-Datensicherung. SWPM 1.0 deckt ältere Releases, andere Datenbanken sowie Java- und Dual-Stack-Systeme ab (SAP-Hinweis 2568783).

Für einen konsistenten Export mit R3load empfiehlt SAP, das SAP-System zu stoppen, die Datenbank läuft weiter. Objekte außerhalb des ABAP Dictionary exportiert SWPM nicht. Ist SAP HANA die Quelle und das System auf AS ABAP 7.52, schließt SAP den datenbankunabhängigen Weg aus, weil das System HANA-Artefakte nutzt, die R3load nicht unterstützt.

Nur den Datenbankinhalt ersetzen. Existiert das Zielsystem bereits, bietet SWPM die Option „Refresh Database Content“. Sie ersetzt den Inhalt der Datenbank aus einer Sicherung, ohne die Instanzen neu zu installieren. SAP empfiehlt sie, um den Datenbankinhalt bestehender, fertig konfigurierter Systeme anzugleichen.

Vorbereitung der Systemkopie

Eine Systemkopie mit Produktionsdaten braucht einen Plan. Aus dem SAP-Leitfaden und der Praxis ergeben sich diese Punkte:

• Zeitpunkt und Testlauf: Kopien mit Produktionsdaten mit Monats- und Jahresabschlüssen abstimmen. Ein Testlauf zeigt, wie lange Sicherung, Übertragung und Wiederherstellung dauern, und damit die nötige Ausfallzeit.
• System-ID: Jedes System braucht eine eigene, eindeutige SID. SAP-Hinweis 1979280 listet die reservierten IDs.
• Version und Plattform: Die HANA-Version im Ziel muss gleich oder höher sein als in der Quelle, und beide Plattformen brauchen dieselbe Byte-Reihenfolge (Endianness). Den Mindest-Patch-Level des Kernels für den Support-Package-Stand der Quelle prüfen.
• Speicher: Das Ziel braucht Plattenplatz und Hauptspeicher für die komplette Datenbank, also etwa das Sizing der Produktion.
• Lizenzen: Einen neuen SAP-Lizenzschlüssel und eine HANA-Lizenz für das Ziel einplanen. Der Schlüssel der Quelle gilt im Zielsystem nicht.
• Quellsystem: Abgebrochene oder offene Verbuchungen in SM13 bereinigen, die Einplanung freigegebener Jobs mit dem Report BTCTRNS1 aussetzen (SAP-Hinweis 37425) und Betriebsartenwechsel (SM63) während der Kopie vermeiden. Bei einer Kopie aus der laufenden Produktion ist das Aussetzen der Jobs in der Quelle meist nicht gewünscht. Dann setzen Sie die Jobs erst im Zielsystem aus, bevor dort Hintergrundprozesse starten.
• Bestehendes Zielsystem: Vor dem Überschreiben die logischen Systemnamen aller Mandanten (SCC4) notieren und systemspezifische Einstellungen sichern. Was dazugehört, zeigt das Runbook für den QS-Refresh.
• Sicherung schützen: Die Datensicherung enthält alle Produktionsdaten. SAP weist darauf hin, sie über ihren gesamten Lebenszyklus vor unberechtigtem Lesen und Ändern zu schützen, etwa durch Verschlüsselung.

Anleitung: homogene SAP-Systemkopie mit HANA Backup/Restore und SWPM

Für S/4HANA ab 1809 beschreibt SAP den Ablauf im Systemkopie-Leitfaden zu SWPM 2.0. Als Kurzanleitung:

1. Zieldatenbank bereitstellen. SAP HANA im Zielsystem installieren, in gleicher oder höherer Version als die Quelle.
2. Quelle sichern. Eine vollständige Datensicherung (Complete Data Backup) der Quelldatenbank erstellen, zum Beispiel mit SAP HANA Studio oder Cockpit, als Datei oder über Backint.
3. Sicherung übertragen. Alle Dateien der Sicherung in ein Verzeichnis kopieren, das die Zieldatenbank lesen kann.
4. SWPM starten. Im Software Provisioning Manager die Systemkopie für das Zielsystem wählen. Im Bild zur Datenbank die homogene Systemkopie per SAP HANA Backup/Recovery auswählen.
5. Schema und Sicherung angeben. Schema-Namen und Kennwörter der Quelle eingeben, so wie sie in der Sicherung stehen. Dann Verzeichnis und Präfix der Sicherung angeben, bei Backint die Datenbank-SID der Quelle. SWPM stellt die Datenbank im Ziel wieder her.
6. HANA-Lizenz einspielen. Weil die Sicherung aus einer anderen Datenbank stammt, braucht das Ziel eine neue Lizenz.
7. Nacharbeiten. Falls Sie die Jobs in der Quelle ausgesetzt haben, dort mit BTCTRNS2 wieder freigeben. Im Zielsystem die Checkliste unten abarbeiten.

Mit der Option „Refresh Database Content“ entfällt die Neuinstallation. Sie stoppen die Anwendungsserver des Ziels, lassen die ASCS-Instanz laufen und wählen in SWPM die Option für SAP HANA unter den generischen Optionen. Der Schema-Name im Ziel muss dem in der Sicherung entsprechen. Die Besonderheiten der homogenen Kopie auf SAP HANA beschreibt SAP-Hinweis 1844468.

Wie lange dauert eine SAP-Systemkopie?

Eine feste Dauer gibt es nicht. Die Laufzeit hängt vor allem von der Größe der Datenbank ab und setzt sich aus mehreren Teilen zusammen:

• Sicherung der Quelle: Die SAP-HANA-Datensicherung läuft im laufenden Betrieb. Ihre Dauer hängt von Datenvolumen und Sicherungsziel ab, also Datei oder Backint.
• Übertragung: Die Sicherungsdateien müssen dort liegen, wo die Zieldatenbank sie lesen kann. Netz und Speicher zwischen den Systemen bestimmen, wie lange das dauert.
• Wiederherstellung im Ziel: SWPM stellt die Datenbank aus der Sicherung wieder her. Mit der Option „Refresh Database Content“ entfällt die Neuinstallation der Instanzen.
• Nacharbeiten: Transportwesen, RFC-Verbindungen, Jobs und Benutzer kosten Zeit, ebenso der BDLS-Lauf über alle Tabellen. Dazu kommen Transporte, die im Ziel erneut importiert werden müssen.

Ausfallzeit hat vor allem das Zielsystem: Es steht vom Beginn der Wiederherstellung bis zum Ende der Nacharbeiten nicht zur Verfügung. SAP empfiehlt einen Testlauf, um diese Ausfallzeit zu bestimmen. Mit jedem Jahr Historie in der Produktion wird sie länger.

Nacharbeiten nach der Systemkopie: Checkliste

Nach der Kopie hat das Zielsystem die Verbindungen, Jobs und Einstellungen der Quelle. Ohne Nacharbeiten kann es Partnersysteme der Produktion ansprechen oder Ausgaben an echte Empfänger schicken. Die wichtigsten Schritte für das ABAP-System nach dem SAP-Leitfaden:

• Lizenz: Den neuen Lizenzschlüssel in SLICENSE einspielen.
• Transportwesen: In SE06 die Nachbearbeitung für „Datenbankkopie oder Migration“ ausführen, dann in STMS Domäne, Transportparameter und Transportwege einrichten. Den Transport-Dispatcher in Mandant 000 mit dem Report RDDNEWPP neu einplanen.
• Logische Systeme: Hat sich die SID geändert, die logischen Systemnamen mit BDLS umsetzen. Die Mandanteneinstellungen in SCC4 prüfen.
• RFC und Schnittstellen: RFC-Destinationen in SM59, tRFC in SM58 und qRFC in SMQR prüfen. Verbindungen zur Produktion umstellen oder löschen, sekundäre Datenbankverbindungen in DBCO anpassen.
• Jobs: Abgebrochene und beendete Jobs löschen, die im Ziel benötigten Jobs anpassen und erst dann die ausgesetzten Jobs mit BTCTRNS2 freigeben.
• Druck und Ausgabe: Drucker und Spool-Server in SPAD anpassen, alte Spool-Aufträge löschen (RSPO0041). Den E-Mail-Versand (SCOT) prüfen, bevor Nachrichten echte Empfänger erreichen.
• Profile und Betriebsarten: Die Tabellen TPFET und TPFHT leeren, Profile in RZ10 importieren, Betriebsarten (RZ04, SM63), Anmeldegruppen (SMLG) und RFC-Servergruppen (RZ12) anpassen.
• Sicherheit: Die PSEs in STRUST durch neue mit den Daten des Zielsystems ersetzen und den Secure Store in SECSTORE prüfen.
• Benutzer: Systembenutzer und Berechtigungen überarbeiten (SU01). Bei einem Refresh die gesicherten Benutzer des Zielsystems zurückspielen.
• Dateisystem: Verzeichnisse, NFS-Mounts, externe Kommandos (SM69) und logische Dateipfade (FILE) prüfen, die auf die Produktion zeigen können. Den Zugriff auf Archivdateien der Quelle klären.
• Prüfungen: Konsistenzprüfung (SM28), Systemlog (SM21), Datenbank (DB02) und Server (SM51).
• Datenschutz: Personenbezogene Daten maskieren, bevor Tester und Entwickler zugreifen. Worauf es dabei ankommt, zeigt der Artikel Personenbezogene Daten in SAP-Testsystemen.

SAP bietet für viele dieser Schritte die ABAP Post-Copy Automation mit vordefinierten Aufgabenlisten im ABAP Task Manager (STC01). Laut Leitfaden setzt sie eine Lizenz für SAP Landscape Management Enterprise Edition voraus. Was nach einer Mandantenkopie anfällt, zeigt die Checkliste im Grundlagenartikel zur Mandantenkopie.

Systemkopie oder Mandantenkopie?

Die Systemkopie ist das richtige Werkzeug, wenn ein vollständiges Abbild gebraucht wird: für Last- und Performancetests mit dem vollen Datenvolumen, für neue Systeme mit dem Stand der Produktion und für Hardware- oder Plattformwechsel.

Für den regelmäßigen Refresh von QS- und Testsystemen hat sie Nachteile. Sie überschreibt den Entwicklungsstand im Ziel. Transporte, die noch nicht produktiv sind, müssen danach erneut importiert werden. Das Ziel braucht so viel HANA-Speicher wie die Produktion, und BDLS muss die gesamte Datenbank durchsuchen.

Eine Mandantenkopie lässt Repository und andere Mandanten unberührt, bringt mit den Standardwerkzeugen aber die komplette Historie mit. Hier setzt der Data Refresh Operator an. Er kopiert eine Zeitscheibe, zum Beispiel die letzten 90 Tage, plus alle abhängigen Objekte aus älteren Jahren, bis nachweisbar nichts fehlt. Logische Systemnamen ersetzt DRO beim Import, bevor die Daten in die Datenbank geschrieben werden. Ein nachträglicher BDLS-Lauf entfällt.

–75 %

HANA-RAM in Non-Prod

–60 %

Storage und Backup

Richtwerte aus Referenzszenarien. Die tatsächlichen Effekte hängen von Systemgröße, Historie und Refresh-Zyklen ab. DRO läuft ab SAP S/4HANA 2023.

DRO ersetzt die Mandantenkopie, nicht die Systemkopie. Für Last- und Performancetests, neue Systeme und Plattformwechsel bleibt die Systemkopie mit SWPM das Mittel der Wahl. Die drei Verfahren im direkten Vergleich zeigt die Seite Systemkopie, Mandantenkopie und Zeitscheibe im Vergleich. Warum BDLS nach einer Systemkopie so lange läuft, lesen Sie im Artikel BDLS nach System- und Mandantenkopie.

Häufige Fragen zur SAP-Systemkopie

Quellen

• SAP-Hilfe: System Copy for SAP ABAP Systems Based on UNIX: SAP HANA 2.0 Database, Using Software Provisioning Manager 2.0 (PDF)
• SAP-Hilfe: 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-Hilfe: Processing After Installation of the CTS (Transaktion SE06)
• SAP-Hinweis 1844468: Homogeneous system copy on SAP HANA (SAP-Support-Portal, Anmeldung nötig)
• SAP-Hinweis 2568783: Release Note for Software Provisioning Manager 2.0 (SAP-Support-Portal, Anmeldung nötig)
• SAP Knowledge Base Article 2379836: Homogeneous or Heterogeneous system copy in case of minor OS change