Come risolvere l’errore VSS E WRITERROR RETRYABLE durante il backup della copia passiva del database in un DAG di Exchange?
Riassunto: In una configurazione di Database Availability Group (DAG) in Exchange Server, può incontrare l'errore VSS_E_WRITEERROR_RETRYABLE durante il backup di una copia passiva del database. In questo articolo, discuteremo questo errore in dettaglio e le possibili soluzioni per risolverlo. Citeremo anche uno strumento di riparazione del database di Exchange per riparare il database nel caso in cui le possibili soluzioni non funzionino.
In un Gruppo di disponibilità di database (DAG) di Exchange Server, quando cerca di eseguire il backup di una copia passiva di un database, può verificarsi una situazione in cui il backup fallisce con un errore. Quando controlla il Visualizzatore eventi, può notare il seguente errore.
Nome del writer: 'Microsoft Exchange Writer'.
Id del writer: WriterId
Id istanza del writer: WriterInstanceId
Stato: [1] Stabile
Ultimo errore: Errore riproducibile
Nota: questo errore si applica a Exchange Server 2013 e Exchange Server 2016.
Se esegue nuovamente il backup, potrebbe riscontrare nuovamente lo stesso errore. Può eseguire lo strumento BETest Tool – uno strumento gratuito di Microsoft – per testare le operazioni di backup e ripristino avanzate sul server. Questo strumento verificherà i seguenti elementi:
- Backup incrementale e differenziale
- Opzioni di ripristino avanzate
- Opzioni di roll-forward
Tuttavia, quando si esegue questo strumento, si otterrà ancora il seguente errore, in qualche modo simile all’errore precedente.
Stato per il writer Microsoft Exchange Writer: STABILE(0x800423f3 - VSS_E_WRITERERROR_RETRYABLE)
Sul server in cui viene avviato il backup della copia passiva del database, può notare che nel Registro applicazioni viene registrato un evento con ID 2153 relativo al servizio Exchange Server Replication.
Nome del registro: Applicazione
Fonte: MSExchangeRepl
Data: <Data>
ID evento: 2153
Categoria di attività: Servizio
Livello: Errore
Parole chiave: Classico
Utente: N/A
Computer: <Nome del computer>
Descrizione: La copiatrice di log non è riuscita a comunicare con il server <FQDN dell'Active Server>. La copia del database <Database della casella di posta elettronica del server locale> è in uno stato di disconnessione. L'errore di comunicazione è stato: Si è verificato un errore durante la comunicazione con il server <Server attivo>. Errore: Impossibile leggere i dati dalla connessione di trasporto: Una connessione stabilita è stata interrotta dal software della macchina host. La copiatrice riproverà automaticamente dopo un breve ritardo.
Cause alla base dell’errore VSS_E_WRITERERROR_RETRYABLE
Sembra che il problema sia legato a VSS. Tuttavia, l’errore potrebbe anche verificarsi a causa di alcuni problemi sottostanti al database attivo o alla configurazione di Exchange Server che potrebbero ostacolare il processo. Nella maggior parte dei casi, l’errore è causato da problemi di rete o latenza durante la comunicazione con il servizio Remote Procedure Call (RPC) tra il server in cui risiede la copia passiva e il server che ospita il database attivo. RPC è un protocollo di Exchange Server che viene utilizzato per passare le comunicazioni, MAPI e i dati tra i server Exchange. Questo protocollo è noto anche come Outlook Anywhere. Se questo protocollo non funziona, il database passivo non riceverà alcun aggiornamento dal database attivo.
Possibili soluzioni per risolvere l’errore VSS_E_WRITERERROR_RETRYABLE
Può provare le seguenti soluzioni per risolvere questo errore.
Soluzione – 1
Deve innanzitutto controllare la rete tra i server attivi e passivi per capire se c’è una latenza tra i server che sta raggiungendo un picco o se una porta/traffico particolare è bloccata tra le due fonti.
Soluzione – 2
Può controllare il firewall di Windows sui server per vedere se il traffico viene negato. Dovrebbe controllare le applicazioni di sicurezza del server, come la Data Loss Prevention (DLP), l’antivirus o l’antimalware per vedere se qualche processo viene bloccato sui server.
Soluzione – 3
Deve assicurarsi che il servizio Microsoft Exchange RPC Client Access sia in funzione. Se c’è un problema, si troverà in uno stato di arresto.
Soluzione – 4
Può anche controllare il timeout nei dispositivi di rete dei server Exchange. Il valore di KeepAliveTime deve essere inferiore al timeout della sessione inattiva per garantire che non ci siano timeout. Si tratta di un valore nel registro di Exchange Server che deve essere regolato e aggiornato in base al timeout. Il valore predefinito di questa voce è 30 secondi. Per aumentare il timeout, può aprire l’Editor del Registro di sistema su ciascun server e procedere come segue.
- Apra l’Editor del Registro di sistema e cerchi il percorso seguente.
HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\ExchangeServer\v15\Replay\Parametri
- Crea una nuova voce DWORD (32 bit) con il nome QueryLogRangeTimeoutInMsec.
- Modifichi il valore e clicchi su Decimale.
- Inserisca il valore in secondi. Se desidera impostarlo a 200 secondi, deve inserire 200000. Questo dipende dai requisiti aziendali e dalla latenza tra i due server.
Una volta fatto questo, può riavviare il Servizio di Replica di Microsoft Exchange e quindi riprovare il backup.
Considerazioni sul backup del DAG
Per avviare il backup di una copia passiva del database, il servizio di replica di Exchange sul server del database passivo crea una query per ottenere l’intervallo dei registri delle transazioni sul server del database attivo. Se il server di database attivo è occupato, la query può richiedere più tempo del previsto, soprattutto se ci sono molti file di registro. Quindi, il servizio di replica di Exchange apre un canale RPC verso il server del database attivo per informare il server che è in corso un backup. Il canale RPC deve rimanere aperto durante il backup.
Consideri i seguenti punti sui backup del DAG:
- Utilizzi solo le copie attive del database per i backup. Non è consigliabile eseguire il backup delle copie passive del database. Le copie passive del database devono essere dedicate alle operazioni commerciali in corso. Il backup della copia attiva sarebbe sufficiente per recuperare i dati in caso di guasto.
- Se per qualche motivo deve eseguire il backup di copie passive del database, si assicuri che le copie attive del database non siano configurate per il backup allo stesso tempo. In caso contrario, si verificherà un fallimento del backup e potrebbe verificarsi l’errore RETRYABLE.
- Durante il backup, i database non dovrebbero essere spostati su un altro Exchange Server nel DAG.
- Le connessioni di rete devono essere attive e stabili.
Quando si dispone di un DAG e si utilizzano copie attive e passive di un database, si consiglia di utilizzare Exchange Admin Center o Exchange Management Shell per monitorare la salute e lo stato di ciascuna copia e per eseguire altre attività di gestione associate alle copie del database. Se si verifica un problema e i database non si sincronizzano, subirà una perdita di dati a causa dell’incoerenza dei dati.
Cosa succede se le soluzioni di cui sopra falliscono?
Se tutte le soluzioni di cui sopra falliscono, significa che ci sono problemi di fondo con le copie attive e passive del database o con lo stesso Exchange Server. Cosa succede se la copia attiva è danneggiata e deve recuperare i dati dalla copia? Può utilizzare i registri di una copia passiva del database per recuperare i dati dai file di registro della copia attiva del database. Riproducendo i registri sulla copia del database, può recuperare il database fino ad un punto specifico nel passato. Il processo è difficile perché deve manipolare manualmente i file di registro ed eseguire le utility del database di Exchange Server. In questo caso, non è possibile recuperare i dati completi.
Cosa succede se le copie attive e passive sono entrambe danneggiate? In queste situazioni, può utilizzare Stellar Repair for Exchange. Questo software di recupero di database di Exchange può aprire qualsiasi database di Exchange Server di qualsiasi dimensione. Può sfogliare l’archivio dati ed esportare il database recuperato in PST e altri formati di file. In questo scenario, può creare un nuovo database ed esportare il file EDB recuperato direttamente in un database Exchange Server live.