NetBackup-SQL-Restore: „Partially Successful“ bei Logs beheben

Ein NetBackup-SQL-Server-Restore kann „partially successful" anzeigen, selbst wenn die Datenbankdateien und Transaktionslogs in den erwarteten Verzeichnissen liegen. Im gemeldeten Fall lag das eigentliche Problem in der Restore-Batch-Vorlage: In mehreren Abschnitten mussten noch Kommentare entfernt, Zielpfade aktualisiert und der abschließende Recovery-State korrekt gesetzt werden.

Deshalb muss die Fehlersuche beim SQL-Restore die Dateiablage vom Datenbank-Recovery-State trennen. .mdf- und Log-Dateien auf der Festplatte zu sehen beweist, dass ein Teil des Restores gelaufen ist. Es beweist nicht, dass das gesamte Restore-Skript wie vorgesehen abgeschlossen wurde.

Warum kann ein Restore laufen und trotzdem nur „partially successful" sein?

NetBackup bewertet den Restore-Vorgang, nicht nur ob irgendwelche Dateien erschienen sind. Ein Batch-Skript kann einen Teil der Wiederherstellung abschließen, während ein anderer Abschnitt übersprungen, auskommentiert, fehlerhaft oder im falschen Recovery-State belassen wird.

Der Administrator in der Diskussion erstellte eine Move-Vorlage und stellte die Transaktionslogs so ein, dass sie nicht wiederhergestellt (unrecovered) blieben. Die Datenbank und die Logs erschienen am erwarteten Ort, aber der Job meldete weiterhin einen Teilerfolg mit unklaren User- und Inf-Meldungen.

Ein NetBackup-Teilnehmer riet dazu, das Batch-Skript selbst zu prüfen. Die entscheidende Korrektur bestand darin, die Kommentare in den erforderlichen Abschnitten zu entfernen, die Zielpfade zu aktualisieren und den Recovery-State für jede Stufe korrekt zu setzen.

Das ist eine sinnvolle Reihenfolge bei der Fehlersuche. Validieren Sie Skriptsyntax und Restore-Sequenz, bevor Sie annehmen, dass Medium, SQL Server oder Backup-Image fehlerhaft sind.

Was sollte in einer NetBackup-SQL-Move-Vorlage geprüft werden?

Prüfen Sie jeden MOVE-Abschnitt, der ursprüngliche SQL-Server-Dateien auf ihr Restore-Ziel abbildet. Die SQL-Server-Dokumentation von NetBackup zeigt, dass eine generierte Vorlage auskommentierte TO-Zeilen und Platzhalterpfade enthalten kann, die beim Verschieben der Datenbank bearbeitet werden müssen.

Das Wichtige daran ist die Wiederholung. Ein Restore mit einer vollständigen Datenbank plus differenziellen oder Transaktionslog-Images kann mehrere Abschnitte enthalten, die konsistent bearbeitet werden müssen. Nur den ersten .mdf-Pfad zu korrigieren reicht nicht aus, wenn spätere Log-Restore-Blöcke noch Vorlagenkommentare oder alte Ziele enthalten.

Prüfen Sie den logischen Datenbankdateinamen, den physischen Zielpfad und ob die betreffende Zeile aktiv statt auskommentiert ist. Verfahren Sie ebenso mit Datendateien und Log-Dateien.

Speichern Sie eine saubere Kopie des finalen Skripts. Eine Restore-Vorlage ist Recovery-Code für den Produktivbetrieb. Behandeln Sie sie wie Code — mit Versionskontrolle oder zumindest einem bewährten Runbook — statt als Ad-hoc-Datei, die während eines Ausfalls bearbeitet wird.

Was bewirkt NORECOVERY beim Transaktionslog-Restore?

Eine SQL-Server-Restore-Sequenz hält die Datenbank normalerweise im Zustand „restoring", solange noch weitere Backup-Images angewendet werden müssen. In NetBackup-Vorlagen bedeutet das, dass Zwischenschritte das Äquivalent zum No-Recovery-Verhalten von SQL Server verwenden sollten, damit das nächste differenzielle Backup oder Transaktionslog die Kette fortsetzen kann.

Der letzte Schritt ist anders. Sobald das letzte erforderliche Log angewendet ist, muss die Datenbank recovert werden, damit SQL Server sie online bringt. Bleibt der letzte Schritt unrecovered, können die Dateien vorhanden sein und der Restore aus Sicht der Anwendung trotzdem unfertig wirken.

Der Administrator aus dem Reddit-Fall stieß genau auf dieses Problem der zweiten Stufe. Nachdem das Skript lief, war die Datenbank weiterhin nicht online, obwohl in den Transaktionslog-Abschnitten Recovery angegeben war. Das ist eine Erinnerung daran, den Recovery-State des abschließenden Restore-Vorgangs zu prüfen, nicht nur jeden Block für sich.

Nutzen Sie SQL Server selbst, um den Datenbankzustand zu bestätigen, nachdem der NetBackup-Job abgeschlossen ist.

Warum ist der Recovery-Workflow der Web UI einfacher?

Recovery Points in der NetBackup Web UI reduzieren die Zahl der manuellen Vorlagenbearbeitungen bei unterstützten SQL-Server-Workflows. Die aktuelle Dokumentation erlaubt es einem Administrator, einen vollständigen, differenziellen oder Transaktionslog-Recovery-Point auszuwählen und einen bestimmten Recovery Point, einen anderen Zeitpunkt oder eine Transaction Mark zu wählen.

Das ist besonders nützlich, wenn das Ziel eine punktgenaue Wiederherstellung ist statt eines komplexen Datenbank-Umzugs. Die UI kann die Restore-Sequenz und die Zielauswahl steuern, ohne dass der Administrator jeden Abschnitt der Batch-Datei von Hand bearbeiten muss.

Der Teilnehmer in der Diskussion nannte die Batch-Methode „oldschool" und schlug die Web UI vor, weil sie mehr von der Recovery-Einrichtung automatisch übernimmt. Das ist eine sinnvolle Wahl, wenn NetBackup-Version und SQL-Konfiguration den Web-UI-Workflow unterstützen.

Verwerfen Sie das Skript-Wissen trotzdem nicht. Batch-Vorlagen bleiben nützlich für wiederholbare Automatisierung, komplexe Umzüge auf alternative Pfade und Umgebungen, in denen die Wiederherstellung außerhalb der UI dokumentiert werden muss.

Wie sollte eine punktgenaue Wiederherstellung validiert werden?

Definieren Sie das genaue Ziel, bevor Sie beginnen. „Die Datenbank von gestern wiederherstellen" ist vage. „Die Datenbank auf 14:04:30 Uhr vor der fehlerhaften Transaktion wiederherstellen" ist testbar.

Bestätigen Sie, dass das Vollbackup, etwaige differenzielle Backups und die erforderliche Transaktionslog-Kette bis zu diesem Punkt vorhanden sind. Führen Sie den Restore dann über den unterstützten NetBackup-Workflow durch und prüfen Sie den finalen Datenbankzustand in SQL Server.

Nachdem die Datenbank online ist, führen Sie Prüfungen auf Anwendungsebene durch. Kontrollieren Sie erwartete Tabellen, aktuelle Datensätze, Logins, Jobs und abhängige Dienste. Eine als online markierte Datenbank kann trotzdem der falsche Recovery Point sein.

Deshalb ist der Ansatz aus dem Leitfaden zu VM- versus Datenbank-Backup mit seinen getrennten Wiederherstellungsebenen relevant. Ein VM-Restore kann den Server zurückbringen, während ein Transaktionslog-Restore eine viel präzisere Datenbankfrage beantwortet.

Welche Logs und Belege sollten Sie nach einem erfolgreichen Restore sichern?

Sichern Sie die finale funktionierende Vorlage oder dokumentieren Sie die genauen Auswahlen in der Web UI. Notieren Sie die verwendeten Backup-IDs oder Recovery Points, das Restore-Ziel, die Stop-Zeit, den Recovery-State sowie die SQL-Server-Prüfung, die den Erfolg belegt hat.

Halten Sie außerdem fest, warum der ursprüngliche Job nur teilweise erfolgreich war. Lag die Ursache in auskommentierten Vorlagenabschnitten, dokumentieren Sie das ausdrücklich. Andernfalls behandelt der nächste Administrator dieselbe Warnung womöglich als Medienfehler und startet eine viel größere Untersuchung.

Wiederholen Sie die Wiederherstellung bei kritischen Datenbanken in einer Testumgebung. Der Proxmox-Backup-Server-Leitfaden behandelt eine andere Plattform, aber das operative Prinzip ist dasselbe: Wiederherstellungsverfahren werden erst zuverlässig, nachdem sie geübt wurden.

Messen Sie neben der Korrektheit auch die Restore-Zeit. Ein Skript, das funktioniert, aber bei jedem Vorfall sechs Stunden zur Diagnose braucht, verfehlt trotzdem das operative Ziel.

Was würde ich bei einem nur teilweise erfolgreichen Transaktionslog-Restore tun?

Ich würde aufhören, Storage- oder Backup-Policies zu ändern, und zuerst die Restore-Definition prüfen. Bei einem Batch-Restore würde ich jedes MOVE, jeden Zielpfad, jeden Kommentarmarker und jedes Recovery-State-Feld mit einer bewährten Vorlage und dem aktuellen SQL-Server-Layout vergleichen.

Ist das Ziel eine standardmäßige punktgenaue Wiederherstellung und unterstützt das NetBackup-Release das, würde ich auch den Recovery-Point-Workflow der Web UI testen, weil er die manuelle Bearbeitung reduziert. Nach dem Restore würde ich prüfen, ob SQL Server die Datenbank als online anzeigt und die Daten dem vorgesehenen Zeitpunkt entsprechen.

Eine „Partially Successful"-Meldung ist nicht automatisch eine gescheiterte Wiederherstellung. Sie ist ein Signal, dass der Workflow nur einen Teil dessen abgeschlossen hat, was das Skript verlangte. Finden Sie den fehlenden Schritt, bevor Sie die gesamte Kette erneut ausführen.