AIX sichern und klonen: mksysb, savevg und risikoarme Upgrades mit alt_disk_copy

Ziel

Ein wiederherstellbares Backup von rootvg eines AIX-Systems erstellen, den Inhalt eines mksysb-Images prüfen, ohne es zurückzuspielen, und ein Technology-Level-Update mit einem Rückfallweg auf demselben System durchführen, statt sich allein auf die Wiederherstellung vom Band zu verlassen.

Voraussetzungen

Root-Zugriff; auf dem Zielmedium (Bandlaufwerk, Datei auf einem NIM-Server oder lokale Disk) ausreichend Platz für den gesamten Inhalt von rootvg; für alt_disk_copy eine zusätzliche, ungenutzte Disk, die in lspv sichtbar ist.

Schritte

mksysb-Backup

1. Backup erstellen: mksysb -i /dev/rmt0 (auf Band) oder in eine Datei auf einem NIM-Server. mksysb sichert alle eingehängten JFS/JFS2-Daten in rootvg sowie genügend Informationen, um das Basisbetriebssystem neu zu installieren.
2. Falls das Image später ein anderes System aufsetzen soll, die Rückfrage zur Wiederherstellung der Geräte («recover devices») bei der Wiederherstellung mit «no» beantworten, damit der Gerätebaum des Zielsystems neu erkannt wird und nicht der des Quellsystems übernommen wird.
3. Soll stattdessen eine Volume Group ausserhalb von rootvg gesichert werden, dient savevg -i -f <device-or-file> <vgname>; das Image ist nicht bootfähig und wird auf einem laufenden System mit restvg zurückgespielt.

mksysb prüfen, ohne es wiederherzustellen

4. Das Image mit lsmksysb zerstörungsfrei untersuchen (zum Beispiel lsmksysb -lf <image-file>): Es kann eine zu lslpp -L äquivalente Liste der in diesem rootvg installierten Filesets sowie zu lsvg äquivalente Angaben zu Volume Group und Grösse anzeigen, einschliesslich der Grösse, die das Backup bei einer Wiederherstellung in Minimalgrösse belegen würde.

Risikoarmes Upgrade mit alt_disk_copy

5. Mit lspv eine freie Disk ermitteln (Spalte der Volume Group: None). None bedeutet lediglich, dass darauf keine AIX-Volume-Group aktiv ist. Vor dem nächsten Schritt sicherstellen, dass es sich nicht um ein Raw Device einer Datenbank oder um eine SAN-LUN handelt, die mit einer anderen LPAR geteilt wird, denn der nächste Schritt überschreibt die Disk.
6. Das laufende rootvg darauf klonen: alt_disk_copy -BOd hdiskX. -B belässt die aktuelle Bootlist auf der ursprünglichen Disk, -O setzt die gerätespezifischen ODM-Einträge der Kopie zurück, damit es keine Konflikte gibt, falls sie später auf andere Hardware verschoben wird.
7. Um Klonen und Update in einem Schritt zu kombinieren, werden dem Klonbefehl die Update-Optionen hinzugefügt, zum Beispiel alt_disk_copy -d hdiskX -b update_all -l <lpp_source-directory>; das laufende rootvg bleibt dabei unverändert. (alt_disk_mksysb ist der verwandte Befehl, der ein vorhandenes mksysb-Image auf einer freien Disk installiert; mit -O wird dabei das Geräte-Reset durchgeführt.)
8. Von der alternativen Disk booten (über bootlist oder ein am HMC gewähltes Boot-Device), um die aktualisierte Kopie zu testen. Schlägt das fehl, die Bootlist wieder auf die unveränderte ursprüngliche Disk zurückstellen (oder diese im SMS-Bootmenü auswählen, falls der Klon nicht startet); eine Wiederherstellung ist nicht nötig.

Erwartetes Ergebnis

Ein geprüftes mksysb-/savevg-Image liegt ausserhalb des Systems vor; lsmksysb bestätigt dessen Inhalt an Filesets und Volume Groups; ein mit alt_disk_copy erstellter Klon bootet unabhängig von der ursprünglichen Disk und bietet damit einen Rückfallweg am selben Tag.

Grenzen und Prüfbasis

Dies beschreibt nur die Duplizierung von rootvg; andere Daten-Volume-Groups erfordern savevg/restvg oder ein eigenes Vorgehen. Das Duplizieren von rootvg per bitweiser Diskkopie oder durch Umstecken physischer Disks zwischen Systemen gehört nicht zu den von IBM unterstützten Methoden: Bei direkt angebundenen Disks kann die Kopie möglicherweise nicht booten (LED 554), weil hardwarespezifische ODM-Daten (Location Codes, WWPNs) nicht zur neuen Hardware passen.