Avamar: Hyper-V-Backups schlagen fehl | Zeitüberschreitung beim Warten auf einen VSS-Snapshot
Summary: Dieser Artikel befasst sich mit einem Fehlerszenario in Avamar Hyper-V-Clusterbackups, bei dem Kommunikationsverzögerungen zwischen Cluster-Nodes zu Timeouts bei der VSS-Snapshot-Synchronisation führen. Das Problem wird behoben, indem die Timeout-Parameter in der avhypervvss.cmd-Konfigurationsdatei angepasst werden. ...
Symptoms
Hyper-V-Clusterbackups schlagen mit den folgenden Fehlern fehl:
Vom freigegebenen Cluster var Verzeichnisprotokolle:
-
avhypervvss Error <0000>: The plugin on remote client HYPERVNODE4 (192.168.1.1) terminated with code 10007: miscellaneous error avhypervvss Error <0000>: The remote client HYPERNODE4 failed to start its backup sub-workorder in predefined time. Please examine the log 'Hyper-V_5pm-Hyper-_V-123456789-3032-Hyper-V_VSS.log' on client HYPERVNODE4 for more information. avhypervvss Error <13810>: Unable to forward a ctl message to the remote client '192.168.1.1', result code: 3. avhypervvss Error <41106>: [AV-CLUSTER0] is unable to wakeup sub-workorder on [HYPERVNODE4]. avhypervvss Error <42468>: Failed to update snapshot details from remote clients avhypervvss Error <41659>: Backup did not complete successfully
Aus dem Backupprotokoll auf dem betroffenen Node (C:\Program Files\avs\var):
-
avhypervvss Error <17114>: Timed out while waiting for a VSS snapshot synchronization event from the primary plugin. avhypervvss Error <41632>: Failed to setup and notify primary. avhypervvss Error <41659>: Backup did not complete successfully
Cause
Der Fehler wird durch Kommunikationsverzögerungen beim CTL-Nachrichtenaustausch zwischen den primären und sekundären Nodes im Hyper-V-Cluster verursacht. Diese Verzögerungen verhindern die rechtzeitige Synchronisierung von VSS-Snapshots, was zu Backupfehlern führt.
Resolution
Um das Problem zu beheben, erhöhen Sie die Timeout-Werte in der avhypervvss.cmd Datei auf dem freigegebenen Cluster var Verzeichnis (wie in, C:\ClusterStorage\Volume1\Avamar\var):
Fügen Sie die folgenden Flags hinzu:
--request-ctl-timeout=600000
--subworkorder-timeout=20
--request-ctl-timeout=600000aus: Erhöht das interne CTL-Timeout zwischen Nodes (Standard ist 60 Sekunden).--subworkorder-timeout=20aus: Legt die Wartezeit (in Minuten) für Back-end-Clients zum Starten von Unterarbeitsaufträgen fest (Standardwert ist 5 Minuten).
⚠️ Stellen Sie sicher, dass die Datei auf allen relevanten Nodes aktualisiert wurde, und starten Sie den Backupprozess neu.