NetBackup Tape Restore: Alte Medien prüfen und wiederherstellen

Die Fehlersuche bei NetBackup-Tape hat zwei unterschiedliche Aufgaben, die sich leicht verwechseln lassen: nachzuweisen, dass eine Datei in einem Backup-Image erscheint, und nachzuweisen, dass sich altes physisches Medium noch rekonstruieren und wiederherstellen lässt. Verwenden Sie für die erste Aufgabe bplist oder bpflist, und nutzen Sie dann den unterstützten NetBackup-Import-Workflow, wenn der Katalog verloren ist oder die Bänder aus einer alten Umgebung stammen.

Zwei Administratorfälle zeigen, warum diese Unterscheidung wichtig ist. Ein Administrator wollte eine tägliche Prüfung automatisieren, ob eine bestimmte Datei geschützt worden war, bevor die Quelle gelöscht wird. Ein anderer hatte viele NetBackup-5.1-Bänder und versuchte, einen langsamen Katalog-Import zu umgehen, indem er das Medium mit tar32.exe oder nbtar las.

Wie prüfen Sie, ob sich eine Datei in NetBackup befindet?

Verwenden Sie den NetBackup-Katalog statt eines manuellen Scans des Bandes, wenn die aktuelle Umgebung das Backup-Image noch kennt. Der Befehl bpflist listet gesicherte und archivierte Dateien auf einem NetBackup-Server auf, während bplist eine ähnliche Datei-Auflistung über NetBackup-Hosts hinweg bietet.

Das macht diese Befehle nützlich für die Automatisierung. Ein Skript kann einen Client, einen Datumsbereich, ein Pfadmuster, eine Policy oder eine Backup-ID abfragen und entscheiden, ob die erwartete Datei im Katalog erscheint. Die genauen Filter sind wichtig, weil derselbe Dateiname in mehreren Backups, auf mehreren Clients oder unter mehreren Aufbewahrungsfristen existieren kann.

Der Reddit-Fall war operativ einfach: Die Anzahl der Dateien war zu groß geworden, um sie einzeln in der Oberfläche zu prüfen. Die Prüfung in eine Katalogabfrage zu verlagern ist der richtige Weg, weil die Ausgabe skriptfähig und wiederholbar ist.

Nennen Sie das aber nicht eine vollständige Medienverifizierung. Ein Katalogeintrag sagt, dass NetBackup die Datei in einem Backup-Image erfasst hat. Er beweist nicht, dass ein zehn Jahre altes Band heute lesbar ist, dass das passende Laufwerk verfügbar ist, oder dass sich jedes benötigte Fragment beim Restore einlegen lässt.

Ist bparchive sicherer als ein selbstgeschriebenes Lösch-Skript?

bparchive lohnt sich, wenn die eigentliche Anforderung lautet: „Diese Datei schützen und die Quelle erst entfernen, nachdem das Archiv erfolgreich war." NetBackup dokumentiert bparchive speziell für Archiv-Vorgänge, und sein Verhalten ist an einen Benutzer-Archiv-Zeitplan sowie die zum Löschen der Originaldatei nötigen Berechtigungen gebunden.

Das ist sauberer als ein Skript, das eine Backup-Abfrage durchführt und sofort rm ausführt oder eine Windows-Datei löscht, nur weil der Name irgendwo im Katalog auftauchte. Der Archiv-Workflow hält die Schutzaktion und die Löschentscheidung enger zusammen.

Es gibt weiterhin operative Details, die getestet werden müssen. Ein erfolgreicher Archiv-Job muss die vorgesehene Policy und Aufbewahrungsfrist verwenden. Das Restore-Team muss außerdem wissen, dass die Daten aus einem Archiv-Zeitplan stammen, wenn es später danach sucht. Unter UNIX können Eigentümerschaft und Schreibstatus beeinflussen, ob die Quelle gelöscht wird, selbst wenn die Daten geschützt sind.

Wenn es sich bei den Dateien um Geschäftsunterlagen statt um verzichtbare Staging-Daten handelt, würde ich „Backup erfolgreich" trotzdem von „darf dauerhaft gelöscht werden" trennen. Fügen Sie einen regelmäßigen Restore-Test hinzu, bevor Sie den Abschluss des Archivs zu einem automatischen Bereinigungsauslöser machen. Dieselbe Recovery-first-Idee findet sich im Proxmox-Backup-Vergleich, wo die entscheidende Frage nicht nur ist, ob ein Job abgeschlossen wurde, sondern ob sich das geschützte Objekt in der benötigten Form wiederherstellen lässt.

Warum sind alte NetBackup-Bänder manuell schwer wiederherzustellen?

Alte NetBackup-Medien können deutlich mehr Struktur enthalten als ein normales TAR-Archiv. Im NetBackup-5.1-Fall konnte der Administrator die Bänder auf Festplatte imagen, aber tar32.exe brachte die Daten nicht zum Auflisten oder Extrahieren, und GNU TAR war kein praktikabler Ersatz.

Die Antworten machten das eigentliche Skalierungsproblem deutlich. Jedes Backup-Image kann ein oder mehrere Fragmente enthalten. Ein Image kann sich über mehrere Tape-Dateien oder mehrere physische Bänder erstrecken. Multiplexing kann das Layout von Hand noch schwerer rekonstruierbar machen.

Manuelle Wiederherstellung erfordert deshalb mehr, als Bytes vom Anfang eines Bandes zu lesen. Sie müssen wissen, in welchem Image Sie sich befinden, wo dessen Fragmente beginnen, ob ein anderes Band das Image fortsetzt, und wie die ursprünglichen NetBackup-Metadaten diese Fragmente auf Dateien zurückführen.

Das ist bei einem bekannten Image mit guten Aufzeichnungen machbar. Es wird mühsam, wenn es Hunderte Sessions und viele Bänder gibt.

Was macht der NetBackup-Phase-I-Import tatsächlich?

Phase I durchsucht das Quellmedium und erstellt eine Liste von Backup-Images, die für den Import ausgewählt werden können. Die NetBackup-Dokumentation stellt ausdrücklich klar, dass Phase I das vollständige Backup-Image noch nicht in den Katalog importiert.

Bei Band muss das Medium eingelegt und gelesen werden. Das kann langsam sein, besonders bei einem großen historischen Bestand, aber die Zeit wird sinnvoll genutzt: NetBackup baut die Zuordnung wieder auf, welche Images existieren und welche Medien sie enthalten.

Deshalb kann der zweistufige Prozess weniger arbeitsintensiv sein als eine „schnellere" manuelle Methode. Eine manuelle Extraktion liest Daten vielleicht nur einmal, aber der Administrator wird selbst zum Katalog. Jemand muss Image-Grenzen, Fragmente, Bandwechsel und Dateibesitz von Hand nachverfolgen.

Phase I erlaubt es dem Produkt, genug Metadaten wiederherzustellen, damit der nächste Schritt gezielt statt blind erfolgt.

Was fügt der Phase-II-Import hinzu?

Phase II importiert die ausgewählten Backup-Images und baut die Katalog-Informationen auf Dateiebene wieder auf, die für normales Durchsuchen und Restore benötigt werden. Die NetBackup-Dokumentation weist darauf hin, dass Phase II von Phase I abhängt, weil die erste Phase die relevanten Images und die Medienstruktur identifiziert.

Bei altem Medium sind diese rekonstruierten Metadaten wertvoll. Sie können gezielt nach den Dateien suchen, die Sie tatsächlich brauchen, statt jedes Image auf eine große Scratch-Disk zu dumpen und dann zu versuchen zu ermitteln, was jedes Fragment enthält.

Ein Kommentator in der Band-Diskussion wies außerdem darauf hin, dass ein Image, das sich über mehrere Bänder erstreckt, genau der Fall ist, in dem die Katalog-Rekonstruktion Aufwand spart. NetBackup kennt die Beziehung zwischen den Fragmenten. Ein selbstgebauter Extraktionsprozess muss diese Logik nachbilden.

Wenn Sie viele alte Bänder haben, würde ich den langsamen Scan akzeptieren und den Import-Workflow automatisieren, statt ein Einweg-Wiederherstellungstool zu bauen — es sei denn, es gibt einen sehr konkreten Grund, warum der normale Import nicht funktionieren kann.

Wie sollten Sie die Band-Wiederherstellung testen, bevor Sie Quelldateien löschen?

Testen Sie auf zwei Ebenen. Bestätigen Sie zunächst mit bplist oder bpflist, dass die erwartete Datei im NetBackup-Katalog vorhanden ist. Stellen Sie zweitens eine repräsentative Stichprobe aus der tatsächlichen Kopie wieder her, auf die Sie sich verlassen, besonders wenn Band die einzige erhaltene Kopie ist.

Dieser zweite Schritt ist wichtig, weil die Band-Wiederherstellung von Hardware, Medium, Katalog, Verschlüsselung und operativen Abhängigkeiten geprägt ist. Eine Datei kann perfekt indiziert sein, während das zum Lesen der Kassette nötige Laufwerksmodell nicht mehr verfügbar ist. Eine Library kann gesund sein, während eine bestimmte Kassette Lesefehler hat. Ein Image kann existieren, während ein Fortsetzungsband fehlt.

Für Umgebungen, die zusätzlich diskbasiertes Backup nutzen, liefert der Proxmox-Backup-Server-Leitfaden nützlichen Kontext, weil er zeigt, wie unterschiedliche Storage-Ebenen Restore-Geschwindigkeit und Verifizierung verändern. Band eignet sich hervorragend für Aufbewahrung und Offline-Schutz, sollte aber entsprechend der vom Unternehmen erwarteten Recovery-Zeit getestet werden.

Ich würde Katalogprüfungen automatisieren, das Band-Inventar diszipliniert pflegen und echte Restores einplanen. Wenn die Daten wichtig genug sind, um sie vom primären Storage zu löschen, sind sie wichtig genug, um nachzuweisen, dass die verbleibende Kopie zurückgeholt werden kann.