Avamar: Backup Hyper-V non riusciti | Timeout durante l'attesa di un'istantanea VSS
Summary: Questo articolo affronta uno scenario di errore nei backup del cluster Avamar Hyper-V in cui i ritardi di comunicazione tra i nodi del cluster causano timeout di sincronizzazione delle istantanee VSS. Il problema viene risolto regolando i parametri di timeout nel file di configurazione del avhypervvss.cmd. ...
Symptoms
I backup del cluster Hyper-V hanno esito negativo con i seguenti errori:
Dal cluster condiviso var Registri di directory:
-
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
Dal registro di backup sul nodo interessato (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
L'errore è causato da ritardi di comunicazione negli scambi di messaggi CTL tra i nodi primari e secondari nel cluster Hyper-V. Questi ritardi impediscono la sincronizzazione tempestiva delle istantanee VSS, con conseguente errore di backup.
Resolution
Per risolvere il problema, aumentare i valori di timeout in avhypervvss.cmd File che si trova nel cluster condiviso var directory (come in, C:\ClusterStorage\Volume1\Avamar\var):
Aggiungere i seguenti flag:
--request-ctl-timeout=600000
--subworkorder-timeout=20
--request-ctl-timeout=600000: Aumenta il timeout CTL interno tra i nodi (il valore predefinito è 60 secondi).--subworkorder-timeout=20: Imposta il tempo di attesa (in minuti) per l'avvio degli ordini secondari da parte dei client back-end (l'impostazione predefinita è 5 minuti).
⚠️ Assicurarsi che il file sia aggiornato su tutti i nodi pertinenti e riavviare il processo di backup.