Die Funktion „Concurrent Copy“ (CCOPY) bietet eine Möglichkeit der Sicherung (einschließlich Versions-Backup), bei der eine Dateimenge konsistent gesichert und gleichzeitig die Dateien in beliebiger Weise bearbeitet werden können. Dadurch ergeben sich in einem Rechenzentrum gegenüber dem herkömmlichen Sicherungsverfahren erhebliche Zeiteinsparungen.
Bild 9: Verlauf einer Sicherung mit und ohne „Concurrent Copy“
Die CCOPY-Funktion ist besonders für Anwendungen gedacht, die nicht für längere Zeit geschlossen werden können, bei denen aber trotzdem Dateien gesichert werden sollen. Sie benötigt allerdings mehr Betriebsmittel als eine gewöhnliche Sicherung. Die CCOPY-Funktion wird in den Anweisungen BACKUP-FILES durch den Operanden CONCURRENT-COPY aktiviert.
Damit eine Sicherung mit der CCOPY-Funktion angefordert werden kann, muss bei Verwendung einer Arbeitsdatei (WORK-FILE-NAME=*STD bzw. <filename>) eine Dateimenge festgelegt werden, die auf diese Art gesichert werden soll. Diese Dateimenge kann z.B. alle von einer Anwendung benötigten Dateien enthalten. Beim Erstellen des Sicherungsauftrags dürfen diese Dateien höchstens lesend geöffnet sein (Ausnahmen sind die Online-Sicherung mit SHC-OSD auf "Sicherung mit SHC-OSD" sowie die Übernahme einer Snapset-Sicherung auf "Übernahme von Dateien und Jobvariablen aus Snapsets in ein Backup-Archiv"), so dass sie auf einem konsistenten Stand sind. Der Sicherungsauftrag muss erstellt werden mit //BACKUP-FILES ..., CONCURRENT-COPY=*YES. bzw. im Falle des Versions-Backups mit //BACKUP-FILE-VERSIONS ..., CONCURRENT-COPY=*YES.
Nach dem Ende der Initialisierung erhält der HSMS-/Systemverwalter Meldungen, die das Ergebnis dieses ersten Schritts erläutern. Wenn auf seinem System der Jobvariablen-Service aktiv ist, kann der Verwalter über eine Jobvariable abfragen, ob ein Problem aufgetreten ist. Wenn die Sicherung für eine oder mehrere Dateien nicht initialisiert werden konnte, meldet HSMS dem Verwalter, welche Dateien nicht bearbeitet werden konnten.
Ursache dafür kann beispielsweise sein, dass die Datei gesperrt war. Anschließend kann der Verwalter die Ursache beheben und die HSMS-Anweisungen BACKUP-FILES oder BACKUP-FILE-VERSIONS erneut starten.
Wenn während des Sicherungslaufs mit CONCURRENT-COPY=*YES eine oder mehrere Dateien nicht gesichert werden können oder ein Fehler auftritt, wird der Sicherungslauf für die übrigen Dateien nicht abgebrochen; es werden so viele Dateien wie möglich gesichert.
Dateien, die nicht gesichert werden konnten, können in eine spätere Sicherung einbezogen werden. Diese Sicherung kann mit oder ohne CCOPY durchgeführt werden. Die Konsistenz mit den zuerst gesicherten Dateien ist dann aber nicht gewährleistet.
Eine Sicherung mit CONCURRENT-COPY=*YES sichert die Dateien mit einem „gleichzeitigen“ Stand; sonst werden Dateien hintereinander gesichert.
Wenn eine der gewünschten Dateien nicht gefunden wird oder offen ist, wird die Sicherung in diesem Fall so fortgesetzt, als wenn sie ohne CONCURRENT-COPY=*YES gestartet worden wäre.
Bei einer Sicherung mit CONCURRENT-COPY=*YES ist keine Schreibpufferung mit DAB möglich.
Unabhängig von einer etwaigen Backup-Server-Definition werden Sicherungen mit Workfile stets an den Master im SPVS-Verbund geschickt und verarbeitet. Sicherungen von abgetrennten Spiegeln (*BY-ADDITIONAL-UNIT) werden stets lokal bearbeitet.
Sicherung mit Arbeitsdatei
Der standardmäßige Basismechanismus, mit dem für die Sicherung der Datenbestand des Konsistenzpunkts bereitgestellt wird, ist das Schreiben von sog. Before-Image-Dateien: Für die Dauer einer CCOPY-Sicherung wird, bevor ein Block einer in der Sicherungsmenge enthaltenen Datei zum ersten Mal geändert wird, eine Kopie des noch nicht geänderten Blocks in eine Arbeitsdatei geschrieben. Die CCOPY-Sicherung ermittelt aus internen Tabellen, die jeweils beim Schreiben einer Before-Image-Datei aktualisiert werden, ob ein Block aus der Originaldatei oder aus der Arbeitsdatei zu lesen ist.
Die Arbeitsdatei für die Before-Image-Dateien kann entweder standardmäßig von HSMS angelegt werden oder explizit in den HSMS-Anweisungen BACKUP-FILES oder BACKUP-FILE-VERSIONS angegeben werden:
//BACKUP-FILES ..., CONCURRENT-COPY=*YES(WORK-FILE-NAME= –
<filename 1..54 without-gen-vers>)
oder
//BACKUP-FILE-VERSIONS ..., CONCURRENT-COPY=*YES(WORK-FILE-NAME= -
<filename 1..54 without-gen-vers>)
Wenn Dateimengen auf Shared-Pubsets gesichert werden, muss bei expliziter Angabe einer Arbeitsdatei darauf geachtet werden, dass die Arbeitsdatei auf dem Master-Host oder Backup-Server des Shared-Pubset zugreifbar ist. Die Sicherung muss nämlich zwingend auf dem Master-Host oder Backup-Server durchgeführt werden (nicht aber die Erstellung des Sicherungsauftrags an HSMS).
Performance
Durch das Schreiben der Before-Image-Dateien in die Arbeitsdatei, das pro (Groß-)Block eine Lese- und eine Schreiboperation erfordert, sowie durch die interne Verwaltung der Before-Image-Dateien entsteht ein gewisser Mehraufwand an Betriebsmitteln: Ein-/Ausgaben, CPU-Zeit und Speicherplatz für die Arbeitsdatei. Der CPU-Mehrbedarf und die zusätzlichen Ein-/Ausgaben beeinflussen die Performance nachteilig. Sie sind abhängig vom Umfang und der Lokalität der Änderungen, die am Datenbestand parallel zur Sicherung durchgeführt werden. Bei geringer Last sind die Einflüsse entsprechend klein.
Sicherung mit SHC-OSD
Als weiterer Basismechanismus für CCOPY-Sicherungen stehen mit SHC-OSD die Spiegelungsfunktionen der Plattenspeichersysteme im BS2000 zur Verfügung. Dabei werden Platten eines Pubsets innerhalb eines Plattenspeichersystems auf zusätzlichen Platten (Clone-Units) gespiegelt. Diese zusätzlichen Spiegelplatten können bei Bedarf von den Originalplatten abgetrennt und als Pubset-Kopie unabhängig vom Original-Pubset verarbeitet werden. Das Abtrennen und das Wiederzusammenführen der Plattenpaare steuert SHC-OSD. Diese Funktion lässt sich insbesondere auch zur Sicherung nutzen. Sie ist über das Subsystem CCOPY auch in HSMS integriert. Einzelheiten zur BS2000 Host-Komponente für Speichersysteme finden Sie im Handbuch „SHC-OSD“ [23].
Wenn remote in einem zweiten Plattenspeichersystem gespiegelt wird, können wahlweise auch abtrennbare Platten im Remote-Plattenspeichersystem benutzt werden.
Für HSMS-Sicherungen, die Spiegelungsfunktionen eines Plattenspeichersystems mit SHC-OSD nutzen, wird die Spiegelung auf dem Granulat-Pubset, d.h. für alle Volumes eines Pubsets, vorausgesetzt. Die Aufspaltung der Spiegelplatten-Paare wird bei der Initialisierung des Sicherungsauftrags für alle Volumes der beteiligten Pubsets vorgenommen. Während der Aufspaltung werden die Ein-/Ausgaben auf den Pubsets angehalten. Damit sind die folgenden Bedingungen erfüllt:
Die Daten der zu sichernden Dateimenge sind in sich konsistent. Auch schreibend geöffnete Dateien führen nicht zum Abbruch der Sicherung oder können mit der Option SAVE-ONLINE-FILES=*YES wie bei Backup ohne CCOPY gesichert werden.
Die Metadaten des Pubsets auf den abgetrennten Spiegeln (Additional-Units oder Clone-Units) sind konsistent in dem Sinn, dass sie die Rekonstruktion des Pubsets zum Zeitpunkt der Auftrennung erlauben.
Damit ist sichergestellt, dass während der gesamten Sicherung der konsistente Stand der Daten zu Sicherungsbeginn stets zur Verfügung steht. Nachdem die Sicherung erfolgreich beendet wurde, wird die Spiegelung automatisch wieder aufgenommen. Dies kann durch Angabe von DISCARD-COPY=*NO in den Anweisungen BACKUP-FILES oder BACKUP-FILE-VERSIONS verhindert werden. Auf die Behandlung von Fehlerfällen wird unten eingegangen.
Sicherung geöffneter Dateien
Bei der Sicherung von Pubset-Kopien unter CCOPY können auch geöffnete Dateien gesichert werden. Diese Funktion wurde speziell auf Datenbanken zugeschnitten (z.B. SESAM, UDS, ORACLE):
Wenn Datenbanken permanent zugreifbar sein sollen, können sie zum Sichern nicht heruntergefahren und geschlossen werden. Deshalb erfolgt die Sicherung in der Regel bei geöffneter Datenbank. Genauere Hinweise zum Sichern sind in den Handbüchern zu den jeweiligen Datenbanksystemen zu finden.
Mit dieser Variante der Online-Sicherung kann eine Datenbanksicherung wesentlich schneller beendet werden, da die Sperrzeiten für die Datenbankdateien kürzer werden und sich teilweise kleinere LOG-Dateien für die Rekonstruktion eines konsistenten Stands ergeben können.
Spiegelplatten umbenennen
Bei der Aufspaltung werden die Platten der Pubset-Kopie nach folgender Vorschrift umbenannt:
Bei Volumes, deren Name einen Punkt enthält, wird der Punkt durch einen Doppelpunkt ersetzt, z.B. ABC.05 –> ABC:05
Volumes, deren Name mit dem Präfix PUB beginnt, erhalten das Präfix P:B, z.B. PUB500 –> P:B500.
Das Umbenennen ist notwendig, damit nach der Aufspaltung die Volumes auf den Originalplatten und den Spiegelplatten nicht denselben Namen haben. Nur so können die Platten der Pubset-Kopie über einen eindeutigen Namen adressiert werden.
Pubset-Kopie erstellen
Beim Einleiten der Sicherung können Sie in den HSMS-Anweisungen BACKUP-FILES oder BACKUP-FILE-VERSIONS mit CONCURRENT-COPY=*YES(WORK-FILE-NAME=*BY-ADDITIONAL-UNIT) angeben, dass Sie eine Pubset-Kopie nutzen möchten. Dabei ist zu beachten, dass während der Durchführung eines derartigen Sicherungsauftrags die Spiegelplatten der Pubset-Kopie für weitere Sicherungen nicht zur Verfügung stehen. Daher müssen Sicherungsaufträge, die gleiche Spiegelplatten voraussetzen, koordiniert werden.
Nur eine mit //BACKUP-FILES gesicherte Pubsetkopie kann für die Rekonstruktion vollständiger SF- oder SM-Pubsets von Datenspeichern des Originalpubsets und gesicherten Dateien verwendet werden.
Wenn Sie auch geöffnete Dateien sichern wollen, müssen Sie zusätzlich SAVE-ONLINE-FILES=*YES angeben. Es werden aber nur die geöffneten Dateien gesichert, für die die Online-Sicherung mit dem Operanden OPNBACK des CATAL-Makroaufrufs ausdrücklich vereinbart wurde (siehe Handbuch „DVS-Makros“ [22]).
Außerdem ist es möglich, über die Angabe WRITE-CHECKPOINTS=*YES Sicherungsaufträge mit Spiegelplatten wiederanlauffähig und rücksetzbar zu machen (siehe unten). Dies wird empfohlen, da fast kein Zusatzaufwand damit verbunden ist. Andererseits ist damit die Verfügbarkeit des Datenbestands auf dem Stand zu Sicherungsbeginn während der gesamten Sicherungsdauer gewährleistet.
Berechtigung zur Sicherung mit SHC-OSD über Customer-Privilegien
Sicherungen auf Basis von SHC-OSD-Spiegelungsfunktionen binden in größerem Umfang Betriebsmittel, die nicht beliebig verfügbar und vermehrbar sind, sondern deren Einsatz genau geplant werden muss. Daher ist dieser Auftragstyp grundsätzlich Systembetreuern (Privileg TSOS) und HSMS-Verwaltern (Privileg HSMSADM) vorbehalten. Um ggf. auch Anwendungsverwaltern, die nicht über eines dieser Privilegien verfügen, eine Sicherung mit SHC-OSD-Spiegelungsfunktionen zu ermöglichen, kann hierfür zusätzlich ein Customer-Privileg angegeben werden. Die Steuerung über Customer-Privilegien setzt allerdings den Einsatz des Softwareprodukts SECOS (siehe Handbuch „SECOS“ [16]) voraus. Folgende Schritte sind erforderlich:
Es werden ein oder mehrere Customer-Privilegien festgelegt, die zu dieser Sicherung berechtigen. Diese Customer-Privilegien werden dem Subsystem CCOPY beim Start des Subsystems in einer Parameterdatei bekannt gemacht.
Standardmäßig dient dazu die Informationsdatei von CCOPY:SYSSSI.CCOPY.<subsys-vers>Alternativ kann im START-SUBSYSTEM-Kommando mit PARAMETER=‘<filename>‘ eine Parameterdatei mit frei wählbarem Namen angegeben werden; diese Angabe hat Vorrang.
Die Parameterdatei ist eine SAM-Datei mit variabler Satzlänge und enthält genau einen Satz. In diesem Satz werden die Customer-Privilegien für die Sicherung mit SHC-OSD-Spiegelungsfunktionen durch den String CU[STOMER]-PRIV[ILEGES]=(0,1,2,...,8) angegeben. Wenn nur ein einziges Customer-Privileg angegeben wird, können die runden Klammern entfallen. Der Wert 0 bedeutet, dass kein Customer-Privileg zu prüfen ist. Dieser Wert ist standardmäßig in der Informationsdatei von CCOPY festgelegt.
Den Customer-Privilegien, denen wie unter 1. beschrieben die Bedeutung „CCOPY-Sicherung mit SHC-OSD-Spiegelungsfunktionen zulässig“ zugeordnet wurde, werden über die entsprechende SECOS-Funktion eine oder mehrere Benutzerkennungen zugeordnet (siehe Handbuch „SECOS“ [16]).
Performance
CCOPY-Sicherungen mit SHC-OSD-Spiegelungsfunktionen unterscheiden sich in Bezug auf die Performance kaum von Sicherungen ohne CCOPY: Die zu sichernden Daten werden von den abgetrennten Spiegelplatten gelesen, während die parallel zur Sicherung weiter verarbeiteten Dateien auf den Originalplatten liegen. Es besteht also keine Wechselwirkung zwischen Sicherung und Anwendung.
Weil die Katalogzugriffe nicht von den laufenden Platten des Pubsets, sondern lokal von den abgetrennten Platten erfolgen, ist es bei Shared-Pubset-Betrieb nicht sinnvoll, den Auftrag für eine bessere Performance zum Pubset-Master zu verschicken. Deshalb werden CCOPY-Sicherungen mit SHC-OSD-Spiegelungsfunktionen lokal im System des Backup-Aufrufs ausgeführt.
Fehlerbehandlung
Bei CCOPY-Sicherungen mit SHC-OSD-Spiegelungsfunktionen stehen die zu sichernden Daten und alle Metadaten der beteiligten Pubsets auf den Pubset-Kopien mit dem Stand des Konsistenzpunkts zum Beginn der Sicherung zur Verfügung. Damit können im Fehlerfall weitgehende Recovery-Maßnahmen durchgeführt werden, wenn – was empfohlen wird – die Wiederanlauffähigkeit der Sicherung festgelegt wurde. Die Wiederanlauffähigkeit kann in den HSMS-Anweisungen BACKUP-FILES und BACKUP-FILE-VERSIONS oder bei der Definition des Archivs mit WRITE-CHECKPOINTS=*YES definiert werden.
Beim Arbeiten mit SHC-OSD-Spiegelungsfunktionen können durch diese Angabe auch anwendungsbezogene Recovery-Maßnahmen durchgeführt werden. Dagegen ist bei Angabe von WRITE-CHECKPOINTS=*NO das Verhalten wie bei CCOPY-Sicherungen mit Before-Image-Dateien: Es werden von HSMS/CCOPY keine Vorkehrungen zum Wiederaufsetzen getroffen.
Im Folgenden werden mögliche Fehlerfälle und die zugehörigen Möglichkeiten für den Wiederanlauf dargestellt, wenn mit WRITE-CHECKPOINTS=*YES gearbeitet wird:
Fehler im Sicherungslauf
Hier gilt dasselbe wie für Sicherungen ohne CCOPY: Wenn sich der HSMS-Auftrag im Zustand INTERRUPTED befindet, kann er mit der HSMS-Anweisung RESTART-REQUESTS fortgesetzt werden. Nähere Informationen dazu finden Sie im Abschnitt „Aufträge wiederanlaufen lassen (Restart)“.
Systemausfall
Sicherungslauf und restartfähige Anwendung
Nachdem das System wieder verfügbar ist, erfolgt ein Warmstart der Anwendung. Der Sicherungslauf kann mit der HSMS-Anweisung RESTART-REQUESTS fortgesetzt werden. Nähere Informationen dazu finden Sie im Abschnitt „Aufträge wiederanlaufen lassen (Restart)“.Sicherungslauf und nicht restartfähige Anwendung
Nachdem das System wieder verfügbar ist, muss der betroffene Pubset auf den konsistenten Stand zu Sicherungsbeginn zurückgesetzt werden, um die abgebrochene Verarbeitung wiederholen zu können. Dazu sind folgende Schritte erforderlich:Die Originalplatten des Pubsets müssen mit den Spiegelplatten synchronisiert werden. Dies geschieht mit folgendem Kommando, wobei der Pubset nicht importiert sein darf:
/RESTART-FROM-CLONE UNIT=*BY-PUBSET(PUBSET=<catid 1..4>)
(siehe Handbuch „SHC-OSD“ [21]). Damit sind die Daten auf den Stand des Konsistenzpunkts zurückgesetzt.
Nun müssen die Volumes des Pubsets, die jetzt die Archivnummern der Spiegelplatten haben, mit dem Dienstprogramm PVSREN zurückbenannt werden, sodass die Archivnummern wieder der Syntax für Pubsets genügen. Dies geschieht mit der PVSREN-Anweisung:
//RESTORE-LABELS-OF-PUBSET CATID=<catid 1..4>
(siehe Handbuch „Dienstprogramme“ [3])
Der zurückgesetzte Pubset muss importiert werden.
Die abgebrochene Verarbeitung muss wiederholt werden; ggf ist vorher der Sicherungsauftrag erneut zu stellen.
Einschränkungen
Für die Sicherung mit CCOPY gibt es folgende Einschränkungen:
Die Funktionen WRITE-CHECKPOINTS und SAVE-ONLINE-FILES sind nur für Sicherungen von Pubset-Kopien verfügbar.
Privatplatten werden nicht unterstützt.
Eine CCOPY-Sicherung auf einem Shared-Pubset mit Arbeitsdatei (WORK-FILE-NAME=*STD bzw. <filename>) wird stets am Master bearbeitet. Eine CCOPY-Sicherung von Pubset-Kopien wird lokal auf der Seite des Backup-Aufrufs ausgeführt.
Die Migration von Dateien wird in einer CCOPY-Sitzung nicht unterstützt.
Der belegte Speicher einer Datei, die zur sichernden Dateimenge gehört, darf während der gesamten Sicherung nicht mit folgendem BS2000-Kommando reduziert werden:
/MODIFY-FILE-ATTRIBUTES ...,SUPPORT=*PUBLIC-DISK(SPACE=*RELEASE(...))
Eine Datei kann zu einem bestimmten Zeitpunkt nur in einer einzigen CCOPY-Sicherung enthalten sein. Wenn für diese Datei ein Auftrag für eine weitere CCOPY-Sicherung erteilt wird, dann wird dieser Auftrag zurückgewiesen.
CCOPY optimiert die Katalogzugriffe bei der Einleitung der Sicherung von einer Pubset-Kopie.
Übernahme von Dateien und Jobvariablen aus Snapsets in ein Backup-Archiv
Im BS2000 können Pubset-Kopien auf Basis von Snap-Platten (sogenannte Snapsets) erzeugt werden, von denen dann direkt per DMS-Kommando Dateien oder Jobvariablen im Original-Pubset restauriert werden können. Da die Gesamtzahl dieser Snapsets für einen Pubset durch das Plattensubsystem beschränkt ist, muss das Erzeugen und das Löschen von Snapsets im gleichen Turnus erfolgen. Vor dem Löschen eines Snapsets können die auf dem Snapset gesichterten Dateien und Jobvariablen mit der HSMS-Anweisung BACKUP-FILES in ein Backup-Archiv übernommen werden. Angegeben wird dabei die Katalogkennung des Pubsets und das Kennzeichen des zu sichernden Snapsets:
//BACKUP-FILES ..., CONCURRENT-COPY=*YES(WORK-FILE-NAME= –
*FROM-SNAPSET(PUBSET-ID=<catid>,SNAPSET-ID=<snap-id>)
Gegenüber der Sicherung von Pubset-Kopien muss beim Sichern von Snapsets beachtet werden, dass die Dateien und Jobvariablen nicht dem aktuellen Stand zum Zeitpunkt der Bearbeitung von BACKUP-FILES oder BACKUP-FILE-VERSIONS entsprechen, sondern einen Sicherungsstand zum Zeitpunkt der Snapset-Erzeugung repräsentieren. Deshalb erhält die so erzeugte Sicherungsversion im Backup-Archiv oder Versions-Backup-Archiv das Datum der Snapset-Erzeugung.
Wenn im Backup-Archiv bereits neuere Sicherungsversionen vorhanden waren, muss zur Einhaltung der Monotonie der Sicherungsversionen innerhalb einer Sicherungsdatei eine neue Sicherungsdatei erstellt werden. Die Fortsetzung der Sicherungsdatei wird abgewiesen. Die Übernahme von Dateien bzw. Jobvariablen aus Snapsets sollte nicht mit direkten Sicherungen im gleichen Backup- oder Versions-Backup-Archiv kombiniert werden.
Daten von Snapsets können nicht in ein Versions-Backup-Archiv gesichert werden.