Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Versions-Backups reorganisieren

&pagelevel(5)&pagelevel

Das Reorganisieren wird durchgeführt, um Speicherplatz der entsprechenden Speicherebene (S1 oder S2) zu sparen. Es gibt obsolete Dateiversionen (Dateiversionen, die gemäß dem Dateiattribut Anzahl der Backup-Versionen (NUM-OF-BACKUP-VERS) nicht mehr aufbewahrt werden müssen) und Dateien, die vor längerer Zeit aus dem Dateikatalog des Pubsets gelöscht wurden und somit aus dem Versions-Backup-Archiv zu entfernen sind. Das Reorganisieren eines Versions-Backup-Archivs wird mit der Anweisung REORGANIZE-VERSION-BACKUP durchgeführt.  Die Schritte zum Reorganisieren eines Versions-Backup-Archivs lauten wie folgt:

  1. CHECK-CATALOGED-FILES
    Die Anweisung CHECK-CATALOGED-FILES hat drei Funktionen:
    • Aktualisieren des NUM-OF-BACKUP-VERS im Archivverzeichnis pro Datei aus den TSOSCAT-Katalogeinträgen.
    • Prüfen, ob Dateien, die im Archivverzeichnis enthalten sind noch auf dem zugehörigen Pubset existieren. Falls eine Datei vom Pubset gelöscht worden ist, wird die Datei im Archivverzeichnis als gelöscht markiert und das aktuelle Datum als Löschdatum eingesetzt. 
    • Entfernen eines vorhandenen Löschdatums, falls eine Datei wieder restauriert wurde.
    Es wird empfohlen, dass der HSMS-Verwalter während des Prüflaufs Reporte erstellt, um Benutzer über gelöschte Dateien zu informieren. Der Benutzer kann wiederum die Dateien mit der HSMS-Anweisung SHOW-ARCHIVE überprüfen. SHOW-ARCHIVE informiert den Benutzer, welche Dateien HSMS als von der S0-Ebene gelöscht erkannt hat, wann dies erkannt wurde und ob bereits eine Löschung der Dateien aus dem Archiv vorgemerkt wurde.  Falls die Datei versehentlich gelöscht wurde, kann der Benutzer sie wiederherstellen. Falls CHECK-CATALOGED-FILES feststellt, dass die Datei ein Löschdatum hat und  nun inzwischen wieder im TSOSCAT des entsprechenden Pubsets steht, wird das Löschdatum aus dem Datensatz entfernt.
  2. MODIFY-ARCHIVE FILE = *MARK-FOR-DELETION(…)
    Damit eine Datei während der Reorganisation aus dem Archiv gelöscht werden kann, muss sie erst zum Löschen "vorgemerkt" werden. Diese Vormerkung erfolgt mit MODIFY-ARCHIVE  FILE = *MARK-FOR-DELETION(...) und ist erst möglich, nachdem eine gewisse Zeitspanne (SECURE-PERIOD) abgelaufen ist, seit die Datei vom Pubset gelöscht worden ist. Die SECURE-PERIOD ist eine Eigenschaft des Versions-Backup-Archivs. Sie beträgt standardmäßig 180 Tage. Die Datei ist damit „zum Löschen vorgemerkt“, aber das Löschen erfolgt noch nicht. Wenn der HSMS-Verwalter vorhat, die Datei aus dem Archiv zu entfernen, obwohl sie noch auf dem Pubset liegt, muss er die Löschvormerkung mit MODIFY-ARCHIVE FILE = *FORCE-DELETION(...) erzwingen.
  3. REORGANIZE-VERSION-BACKUP
    Zum Schluss wird der eigentliche Reorganisationsprozess mit der Anweisung REORGANIZE-VERSION-BACKUP gestartet. Hier findet das eigentliche Löschen der obsoleten Dateiversionen und der zum Löschen vorgemerkten Dateien aus dem Archiv statt.

Hinweis: Falls CHECK-CATALOGED-FILES bereits durchgeführt wurde und/oder einige Dateien zum Löschen mit MODIFY-ARCHIVE FILE=*MARK-FOR-DELETION(…)/*FORCE-DELETION(...) vorgemerkt waren und kein Reorganisieren erfolgte, werden bei einem folgenden BACKUP-FILE-VERSIONS oder CHECK-CATALOGED-FILES Löschdatum und Löschvormerkung der angegebenen Dateien zurückgesetzt, wenn die Dateien inzwischen restauriert worden sind.  Dazugehörige Hinweise werden im Report ausgegeben.

Der Benutzer kann die Anzahl der aufzubewahrenden Sicherungsversionen im Dateikatalog jederzeit ändern. Diese Änderung wird jedoch nicht sofort in das Archivverzeichnis übertragen, sondern erst, wenn ein Versions-Backup unter Angabe der betreffenden Datei stattfindet, oder die Anweisung CHECK-CATALOGED-FILES aufgerufen wird. D.h. erst anschließend können HSMS Informationsfunktionen oder Reorganisationsläufe die Aktualisierungen im Dateikatalog berücksichtigen.


Sicherung des Archivverzeichnisses bei der Reorganisation

Im Rahmen der Reorganisation eines Versions-Backup-Archivs kann auch das Archivverzeichnis gesichert werden. Diese Funktion wird durch die Angabe SAVE-DIRECTORY=*YES aktiviert. Im Falle einer notwendigen Recovery kann das Archivverzeichnis mittels Import wiederhergestellt werden. Die Attribute eines Archivs werden auch im Archivverzeichnis gespeichert. Wenn die Archivdefinition verloren gegangen ist, kann das Archiv mit der Anweisung CREATE-ARCHIVE (Operand RECONSTRUCT-ARCHIVE = * YES) aus dem Archivverzeichnis wiederhergestellt werden. 

Besonderheiten beim Sichern des Archivverzeichnisses bei der Reorganisation:

  • Die Sicherung des Archivverzeichnisses erfolgt nach Abschluss des eigentlichen Reorganisationslaufs. 
  • Wurde die Reorganisation mit Fehler abgebrochen und wurde keine Sicherungsdatei erzeugt, wird das Archivverzeichnis nicht gesichert. Die Warnung HSM032C wird im Report ausgegeben. Im Rahmen der Fehlerbehandlung kann es zu einer Rückabwicklung kommen, um den vorherigen Zustand wieder herzustellen. Während einer Reorganisation werden Sicherungsdateien auf Platte, die nur obsolete Dateiversionen enthalten, sofort gelöscht. Diese Sicherungsdateien werden bei einer Rückabwicklung nicht wiederhergestellt. Deshalb kann nun der Inhalt des Archivverzeichnisses von dem Inhalt vor dem Lauf abweichen. 
  • Während einer laufenden Reorganisation verhindert eine Sperre im Archivverzeichnis, dass parallel gestartete Reorganisations- oder Sicherungsläufe auf das Archivverzeichnis zugreifen können. Dieser Directory-Lock besteht auch während das Archivverzeichnis am Ende des Laufs gesichert wird. Muss ein so gesichertes Archivverzeichnis restauriert werden, muss vor seiner erneuten Verwendung diese Sperre entfernt werden:

//MODIFY-ARCHIVE ARCHIVE-NAME=<archive-name>, DIRECTORY-LOCK=*UNLOCK-VERSION-DIR 

  • Das Archivverzeichnis wird nicht auf mehrere Volumes verteilt gesichert. Die Sicherung und welcher Datenträger dafür verwendet wurde, wird im Report ausgegeben.

Beispiel:

//BACKUP-FILE-VERSIONS FILE-NAMES=:SSF1:FILE.*,SAVE-OPTIONS=*PARAMETERS(SAVE-DIRECTORY=*YES)
//RVB ARCHIVE-NAME=VERSION.1,SAVE-DIRECTORY=*YES

Aufgrund eines unvorhergesehen Fehlers wurde das Archivverzeichnis gelöscht und muss nun wieder hergestellt werden:

//IMF FILE-NAMES=*DIRECTORY,SAVE-FILE=*BY-VOLUME(SAVE-FILE-ID= <sfid>,VOLUMES=<volume>,DEVICE-TYPE=*STD)

Falls erforderlich (z.B: Umzug des Pubsets an ein anderes System) kann ein neues Archiv unter Verwendung des Archivverzeichnisses folgendermaßen eingerichtet werden:

//CREATE-ARCHIVE ARCHIVE-NAME=<new-archive-name>,DIRECTORY-NAME=<directory>(NEW-DIRECTORY=*NO(RECONSTRUCT-ARCHIVE=*YES))

Wenn nun ein Sicherungslauf für das Versions-Backup-Archiv gestartet wird, kommt es zu folgendem Fehler:

//BACKUP-FILE-VERSIONS FILE-NAMES=<file-names>,SAVE-OPTIONS=*PARAMETERS(SAVE-DIRECTORY=*YES)


HSM032A EIN VERSIONS-BACKUP IST DERZEIT NICHT MOEGLICH, DA EIN REORGANISATIONS-LAUF FUER DASSELBE ARCHIV AUSGEFUEHRT WIRD.
? Es ist nicht moeglich, Reorganisation und Versions-Backup
  
gleichzeitig fuer dasselbe Archiv durchzufuehren.
! Warten Sie auf den Abschluss der Verarbeitung und versuchen Sie es erneut.
  Besteht die Sperre, obwohl keine Auftraege fuer das Archiv bearbeitet werden, entsperren Sie das Archivverzeichnis mittels //MODIFY-ARCHIVE


Wird anstelle von BACKUP-FILE-VERSIONS eine Reorganisation gestartet (REORGANIZE-VERSION-BACKUP), wird im Report die entsprechende Meldung HSM032B ausgegeben. 

Entfernen Sie die Sperre mit der Anweisung MODIFY-ARCHIVE:

//MDA ARCHIVE-NAME=<new-archive-name>,DIRECTORY-LOCK=*UNLOCK-VERSION-DIR