Avamar: Falha nos backups do Hyper-V | Tempo de espera excedido durante a espera por um snapshot do VSS
Summary: Este artigo aborda um cenário de falha nos backups de cluster do Avamar Hyper-V em que atrasos de comunicação entre os nós do cluster causam tempos de espera excedidos de sincronização de snapshot do VSS. O problema é resolvido ajustando os parâmetros de tempo de espera excedido no arquivo de configuração avhypervvss.cmd. ...
Symptoms
Os backups de cluster do Hyper-V apresentam falha com os seguintes erros:
No cluster compartilhado var Logs do diretório:
-
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
No log de backup no nó afetado (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
A falha é causada por atrasos de comunicação nas trocas de mensagens CTL entre os nós principal e secundário no cluster do Hyper-V. Esses atrasos impedem a sincronização oportuna de snapshots do VSS, resultando em falha de backup.
Resolution
Para resolver o problema, aumente os valores de tempo de espera excedido na avhypervvss.cmd arquivo localizado no cluster compartilhado var diretório (como em, C:\ClusterStorage\Volume1\Avamar\var):
Adicione os seguintes indicadores:
--request-ctl-timeout=600000
--subworkorder-timeout=20
--request-ctl-timeout=600000: Aumenta o tempo de espera excedido da CTL interna entre os nós (o padrão é 60 segundos).--subworkorder-timeout=20: Define o tempo de espera (em minutos) para que os clients de back-end iniciem subordens de trabalho (o padrão é 5 minutos).
⚠️ Certifique-se de que o arquivo esteja atualizado em todos os nós relevantes e reinicie o processo de backup.