NetBackup Hyper-V-Fehler 156: Snapshot-Fehler beheben

NetBackup-Status 156 bei Hyper-V bedeutet, dass der Snapshot-Vorgang fehlgeschlagen ist, benennt aber keine einzelne, universelle Ursache. Wenn der Fehler AVHD- oder AVHDX-Disks unkonsolidiert zurücklässt und auch spätere Checkpoints fehlschlagen, behandeln Sie das Ereignis nicht länger als normalen Backup-Retry, sondern untersuchen Sie die Hyper-V-Snapshot-Chain selbst.

Ein Administrator berichtete von mehr als 100 betroffenen Servern, nachdem NetBackup-Snapshot-Versuche den Status 156 zurückgegeben hatten. Die Arbeitshypothese war, dass sich das Passwort eines NetBackup-Service-Accounts geändert hatte, ohne auf den Hyper-V-Hosts aktualisiert worden zu sein, und dass die fehlgeschlagenen Vorgänge Disks hinterließen, die nicht konsolidierten.

Was bedeutet der NetBackup-Hyper-V-Fehler 156 tatsächlich?

NetBackup dokumentiert Status 156 als „snapshot error encountered". Der aktuelle Hyper-V-Leitfaden nennt mehrere mögliche Ursachen statt einer einzelnen, direkten Lösung — darunter falsche VM-Namen in der Policy, unzureichenden freien Speicherplatz für den Snapshot sowie fehlende oder fehlerhafte Hyper-V-Integrationsdienste.

Diese Bandbreite ist wichtig. Ein Statuscode beschreibt, wo der Job fehlgeschlagen ist, nicht warum er in jeder Umgebung dort fehlschlägt.

Sammeln Sie zunächst die NetBackup-Job-Details und die Hyper-V-Ereignisprotokolle einer betroffenen VM. Ermitteln Sie den ersten Snapshot-Fehler, den Host, der ihn ausgelöst hat, und ob Hyper-V selbst außerhalb von NetBackup einen Checkpoint erstellen kann.

Schlägt auch ein manueller Hyper-V-Checkpoint fehl, liegt das Problem unterhalb der NetBackup-Policy-Ebene. Beheben Sie den Zustand der Hyper-V-VM, von VSS, Storage oder Checkpoint, bevor Sie ein weiteres Backup ausführen.

Könnte ein abgelaufenes Service-Account-Passwort die Fehlerkette verursacht haben?

Ja, fehlerhafte Anmeldedaten können Discovery- oder API-Vorgänge stören, aber der Ausgangsfall belegt nicht, dass die Passwortänderung die alleinige Ursache für jedes verbleibende AVHDX-Problem war. Ein Kommentator wies darauf hin, dass NetBackup for Hyper-V in manchen Konfigurationen für Windows-API-Vorgänge von einer Domänenidentität abhängt, und schlug vor zu prüfen, ob die Discovery noch funktioniert.

Das ergibt eine nützliche Unterscheidung. Wenn NetBackup die Hyper-V-Assets nicht durchsuchen oder erkennen kann, verdienen Authentifizierung und Account-Konfiguration sofortige Aufmerksamkeit. Funktioniert die Discovery, schlägt aber die Snapshot-Erstellung fehl, geht es weiter mit der Snapshot- und VSS-Fehlersuche.

Nachdem Sie ein Service-Account-Passwort aktualisiert haben, prüfen Sie die Anmeldedaten überall dort, wo sie gespeichert oder delegiert sind. Testen Sie einen Host und eine VM, bevor Sie den Schutz für die gesamte Flotte neu starten.

Gehen Sie nicht davon aus, dass die Reparatur der Anmeldedaten automatisch auch eine Checkpoint-Chain repariert, die bereits in einem fehlerhaften Zustand zurückgelassen wurde. Die Authentifizierung kann den ursprünglichen fehlgeschlagenen Vorgang erklären, während Hyper-V die daraus entstandenen Differencing-Disks weiterhin zusammenführen oder bereinigen muss.

Warum können nicht konsolidierte AVHDX-Disks künftige Checkpoints blockieren?

Hyper-V-Checkpoints verwenden Differencing-Disks, typischerweise AVHDX-Dateien, die mit den virtuellen Disks der VM eine Parent-Child-Chain bilden. Wird ein Checkpoint gelöscht, führt Hyper-V die Differencing-Daten normalerweise wieder in die Parent-Chain zusammen.

Wird dieser Merge nicht abgeschlossen, kann die VM in einem Checkpoint- oder Disk-Chain-Zustand verbleiben, der saubere neue Snapshots verhindert. Nachfolgende NetBackup-Jobs können dann erneut fehlschlagen, selbst nachdem der ursprüngliche Auslöser behoben wurde.

Deshalb beobachtete der Administrator ein sich wiederholendes Muster von Status 156. Der erste fehlgeschlagene Snapshot erzeugte einen Infrastrukturzustand, der den nächsten Snapshot wahrscheinlicher scheitern ließ.

Löschen Sie AVHDX-Dateien nicht manuell aus dem Dateisystem. Das kann die Chain zerstören und die VM nicht mehr startfähig machen. Verwenden Sie Hyper-V Manager, PowerShell, Ereignisprotokolle sowie von Microsoft unterstützte Merge- oder Checkpoint-Reparaturverfahren, die sich an der tatsächlichen Disk-Beziehung orientieren.

Sollten Sie mehr als 100 VMs neu starten, um Disks zu konsolidieren?

Ein Neustart kann bei manchen Systemen zu helfen scheinen, aber der Neustart eines gesamten Bestands ist keine gute erste Reparaturstrategie. Der Administrator im vorliegenden Fall stellte fest, dass ein Neustart der Server die Disks konsolidierte, wollte aber verständlicherweise nicht mehr als 100 Maschinen neu starten.

Arbeiten Sie stattdessen mit einer Stichprobe. Wählen Sie eine unkritische betroffene VM aus, dokumentieren Sie den Checkpoint-Baum und die AVHDX-Chain vor dem Neustart, und prüfen Sie anschließend genau, was sich ändert. Löst der Neustart eine unterstützte Bereinigung aus, haben Sie jetzt einen Beleg dafür. Ist das nicht der Fall, haben Sie ein Massen-Wartungsereignis ohne Nutzen vermieden.

Gruppieren Sie für die restliche Flotte die VMs nach Symptom. Manche haben möglicherweise veraltete Checkpoints, manche VSS-Fehler, manche zu wenig Speicherplatz, und manche brauchen nur eine Reparatur der Anmeldedaten.

Deshalb spielt auch die Nebenläufigkeit der Backup-Policy eine Rolle. Eine große Welle von Snapshot-Vorgängen kann Hosts, Storage und Management-Komponenten belasten. Begrenzen Sie die parallele Arbeit auf ein Maß, das der Hyper-V-Cluster verkraften kann, statt jede geschützte VM gleichzeitig Snapshots erstellen zu lassen.

Welche weiteren Ursachen für Status 156 sollten Sie prüfen?

Prüfen Sie den freien Speicherplatz innerhalb der relevanten VM-Volumes und auf dem Hyper-V-Storage. Die Hyper-V-Anleitung von NetBackup weist darauf hin, dass unzureichender freier Speicherplatz einen Snapshot-Fehler verursachen kann. Bestätigen Sie außerdem, dass die VM-Namen oder -Kennungen in der Policy noch mit dem tatsächlichen Hyper-V-Inventar übereinstimmen.

Prüfen Sie die Hyper-V-Integrationsdienste im Gastsystem, sofern die unterstützte Konfiguration das erfordert. Kontrollieren Sie anschließend den Zustand der VSS-Writer in Windows-Gästen, die anwendungskonsistente Snapshots benötigen.

Seien Sie vorsichtig mit Ratschlägen, die aus VMware-Fällen übernommen werden. Der Reddit-Thread erwähnte kurz einen Veritas-VSS-Provider, der für bestimmte VMware-Workflows zum Anwendungszustand gilt, und ein anderer Teilnehmer wies zu Recht darauf hin, dass das nicht die Lösung für einen Hyper-V-Fall ist.

Halten Sie die Plattformgrenzen klar auseinander. Das Snapshot-Verhalten von Hyper-V, das Snapshot-Verhalten von VMware und anwendungsbewusste Backups im Gastsystem können alle „Snapshot"-Symptome erzeugen, verwenden dabei aber unterschiedliche Komponenten.

Einen breiteren Vergleich von Virtualisierungs-Backups finden Sie unter Proxmox-Backup-Optionen. Die Plattformen unterscheiden sich, aber dieselbe Regel gilt: Snapshot-Technologie ist Teil des Hypervisor- und Storage-Stacks, sodass ein Backup-Produkt den Vorgang auslösen kann, ohne für jeden darunterliegenden Fehler verantwortlich zu sein.

Wie verhindern Sie einen weiteren Massen-Snapshot-Vorfall?

Beheben Sie zuerst die auslösende Bedingung und verringern Sie dann den Blast Radius. Validieren Sie das Lifecycle-Management der Service-Accounts, damit Passwortänderungen vor dem nächsten geplanten Job in den Backup-Integrationen aktualisiert werden. Überwachen Sie Discovery- und Authentifizierungsfehler getrennt von Snapshot-Fehlern.

Setzen Sie sinnvolle NetBackup-Ressourcenlimits und eine passende Storage-Unit-Nebenläufigkeit. Snapshot-Vorgänge sind nicht kostenlos. Sie erzeugen Management-, Storage- und Merge-Arbeit, die sich während eines großen Backup-Fensters bemerkbar machen kann.

Überwachen Sie nach Backup-Fehlern verbleibende Checkpoints und AVHDX-Dateien. Ein täglicher Bericht, der VMs mit alten Checkpoints oder ungewöhnlichen Differencing-Disk-Chains identifiziert, kann das Folgeproblem erkennen, bevor es auf 100 Server anwächst.

Der Proxmox-Backup-Server-Leitfaden liefert nützlichen Kontext zu einer anderen Plattform, da er verdeutlicht, wie wichtig es ist, Backup-Zustand und Hypervisor-Zustand als getrennte Signale zu behandeln. Ein fehlgeschlagener Job kann ein Backup-Konfigurationsproblem, ein VM-Problem oder ein Storage-Problem sein.

Was würde ich mit der betroffenen Flotte tun?

Ich würde wiederholte Backup-Retries für die betroffene Gruppe einfrieren, da ein weiterer Snapshot-Versuch nichts bringt, solange die Disk-Chain nicht in Ordnung ist. Anschließend würde ich den verdächtigen Service-Account reparieren und nachweisen, dass Asset-Discovery und API-Vorgänge auf einem Hyper-V-Host funktionieren.

Als Nächstes würde ich eine betroffene VM auswählen und feststellen, ob Hyper-V manuell einen Checkpoint erstellen und entfernen kann. Ich würde VSS, freien Speicherplatz, Ereignisprotokolle und die AVHDX-Parent-Beziehungen prüfen und dann die unterstützte Hyper-V-Methode verwenden, um die Checkpoint-Chain zusammenzuführen oder zu bereinigen.

Sobald sich ein Reparaturweg bewährt hat, würde ich das Inventar automatisieren und das validierte Verfahren in kontrollierten Batches wiederholen. Erst wenn die VMs wieder in Ordnung sind, würde ich den NetBackup-Schutz erneut aktivieren.

Status 156 ist der Alarm. Die eigentliche Wiederherstellungsaufgabe besteht darin, herauszufinden, welche Snapshot-Abhängigkeit tatsächlich fehlgeschlagen ist, und den Hypervisor-Zustand vor dem nächsten Backup-Fenster zu bereinigen.