Summary: Dans une configuration DAG (Database Availability Group) d'Exchange Server, vous pouvez rencontrer l'erreur VSS_E_WRITEERROR_RETRYABLE lors de la sauvegarde d'une copie passive de la base de données. Dans cet article, nous discuterons de cette erreur en détail et des solutions possibles pour la résoudre. Nous mentionnerons également un outil de réparation de base de données Exchange pour réparer la base de données au cas où les solutions possibles ne fonctionneraient pas.
Dans un Exchange Server Database Availability Group (DAG), lorsque vous essayez de sauvegarder une copie passive d’une base de données, vous pouvez être confronté à une situation où la sauvegarde échoue avec une erreur. Lorsque vous consultez l’observateur d’événements, vous pouvez remarquer l’erreur suivante.
Nom du rédacteur : "Microsoft Exchange Writer".Id du rédacteur : WriterIdIdentifiant de l'instance du rédacteur : WriterInstanceIdÉtat : [n°1] StableDernière erreur : Retryable error
Remarque : Cette erreur s’applique à Exchange Server 2013 et Exchange Server 2016.
Si vous exécutez à nouveau la sauvegarde, vous risquez de rencontrer la même erreur. Vous pouvez exécuter l’outil BETest Tool – un outil gratuit de Microsoft – pour tester les opérations avancées de sauvegarde et de remise en état sur le serveur. Cet outil testera les éléments suivants :
- Sauvegarde incrémentielle et différentielle
- Options de restauration avancées
- Options rollforward
Cependant, lorsque vous exécutez cet outil, vous obtiendrez toujours l’erreur suivante, similaire à l’erreur ci-dessus.
Statut du rédacteur Microsoft Exchange Writer : STABLE(0x800423f3 - VSS_E_WRITERERROR_RETRYABLE)
Sur le serveur où la sauvegarde de la copie passive de la base de données est initiée, vous pouvez remarquer qu’un événement avec l’ID 2153 est enregistré dans le journal d’application en ce qui concerne le service de réplication du serveur Exchange.
Nom du journal : ApplicationSource : MSExchangeReplDate : <Date>ID de l'événement : 2153Task Category : ServiceNiveau : ErreurMots clés : ClassiqueUtilisateur : N/AOrdinateur : <Nom de l'ordinateur>Description : Le copieur de journaux n'a pas pu communiquer avec le serveur <FQDN de l'Active Server>. La copie de la base de données <Base de données de la boîte aux lettres> est déconnectée. L'erreur de communication était la suivante : Une erreur s'est produite lors de la communication avec le serveur <Serveur actif>. Erreur : Impossible de lire les données de la connexion de transport : Une connexion établie a été interrompue par le logiciel de votre machine hôte. Le copieur effectuera automatiquement une nouvelle tentative dans les plus brefs délais.
Causes de l’erreur VSS_E_WRITERERROR_RETRYABLE
Il semble que le problème soit lié à VSS. Cependant, l’erreur peut également survenir en raison de problèmes sous-jacents liés à la base de données active ou à la configuration d’Exchange Server, qui peuvent entraver le processus. Dans la plupart des cas, l’erreur est causée par des problèmes de réseau ou de latence lors de la communication avec le service Remote Procedure Call (RPC) entre le serveur où réside la copie passive et le serveur hébergeant la base de données active. RPC est un protocole d’Exchange Server utilisé pour transmettre des communications, MAPI et des données entre les serveurs Exchange. Il est également connu sous le nom de Outlook Anywhere. Si ce protocole ne fonctionne pas, la base de données passive ne recevra aucune mise à jour de la base de données active.
Solutions possibles pour corriger l’erreur VSS_E_WRITERERROR_RETRYABLE
Vous pouvez essayer les solutions suivantes pour résoudre cette erreur.
Solution – 1
Vous devez d’abord vérifier le réseau entre les serveurs actifs et passifs pour savoir s’il y a une latence entre les serveurs qui atteint des sommets ou si un port/trafic particulier est bloqué entre les deux sources.
Solution – 2
Vous pouvez vérifier le pare-feu Windows sur les serveurs pour voir si du trafic est refusé. Vous devriez vérifier les applications de sécurité du serveur, telles que la prévention de la perte de données (DLP), l’antivirus ou l’antimalware, pour voir si des processus sont bloqués sur les serveurs.
Solution – 3
Vous devez vous assurer que le service Microsoft Exchange RPC Client Access est en cours d’exécution. En cas de problème, il sera arrêté.
Solution – 4
Vous pouvez également vérifier le délai d’attente dans les périphériques réseau des serveurs Exchange. La valeur de KeepAliveTime doit être inférieure au délai d’inactivité de la session pour garantir qu’il n’y a pas de dépassement de délai. Il s’agit d’une valeur dans le registre du serveur Exchange qui doit être ajustée et mise à jour en fonction du délai d’attente. La valeur par défaut de cette entrée est de 30 secondes. Pour augmenter le délai d’attente, vous pouvez ouvrir l’éditeur du registre sur chaque serveur et faire ce qui suit.
- Ouvrez l’éditeur du registre et recherchez le chemin d’accès ci-dessous.
HKEY_LOCAL_MACHINE\N- SOFTWARE\NMicrosoft\NExchangeServer\Nv15\NReplay\NParamètres
- Créez une nouvelle entrée DWORD (32 bits) appelée QueryLogRangeTimeoutInMsec.
- Modifiez la valeur et cliquez sur Décimal.
- Saisissez la valeur en secondes. Si vous voulez la fixer à 200 secondes, vous devez entrer 200000. Cela dépend des exigences du Business et de la latence entre les deux serveurs.
Une fois cette opération effectuée, vous pouvez redémarrer le service de réplication Microsoft Exchange et réessayer la sauvegarde.
Considérations relatives à la sauvegarde des DAG
Pour lancer la sauvegarde d’une copie de base de données passive, le service de réplication Exchange sur le serveur de base de données passif crée une requête pour obtenir la plage de journaux de transactions sur le serveur de base de données actif. Si le serveur de base de données actif est occupé, la requête peut prendre plus de temps que prévu, surtout s’il y a beaucoup de fichiers journaux. Ensuite, le service de réplication Exchange ouvre un canal RPC vers le serveur de base de données actif pour l’informer qu’une sauvegarde est en cours. Le canal RPC doit rester ouvert pendant la sauvegarde.
Examinez les points suivants concernant les sauvegardes DAG :
- N’utilisez que les copies actives de la base de données pour les sauvegardes. Il n’est pas recommandé de sauvegarder les copies passives de la base de données. Les copies passives de la base de données doivent être consacrées aux opérations commerciales en cours. La sauvegarde de la copie active suffirait à récupérer les données en cas de défaillance.
- Si vous devez sauvegarder des copies passives de la base de données pour une raison quelconque, assurez-vous que les copies actives de la base de données ne sont pas configurées pour être sauvegardées en même temps. Dans le cas contraire, la sauvegarde échouera et l’erreur RETRYABLE risque de se produire.
- Pendant la sauvegarde, les bases de données ne doivent pas être déplacées vers un autre serveur Exchange dans le DAG.
- Les connexions réseau doivent être actives et stables.
Lorsque vous avez un DAG et que vous utilisez des copies actives et passives d’une base de données, il est recommandé d’utiliser le Centre d’administration Exchange ou le Shell de gestion Exchange pour surveiller la santé et l’état de chaque copie et pour effectuer d’autres tâches de gestion associées aux copies de bases de données. Si un problème survient et que les bases de données ne se synchronisent pas, vous subirez des pertes de données en raison de l’incohérence des données.
Que se passe-t-il si les solutions ci-dessus échouent ?
Si toutes les solutions ci-dessus échouent, cela signifie qu’il y a des problèmes sous-jacents avec les copies actives et passives de la base de données ou avec le serveur Exchange lui-même. Que se passe-t-il si la copie active est endommagée et que vous devez récupérer les données de la copie ? Vous pouvez utiliser les journaux d’une copie passive de la base de données pour récupérer les données des fichiers journaux de la copie active de la base de données. En rejouant les journaux sur la copie de la base de données, vous pouvez récupérer la base de données à un moment précis dans le passé. Le processus est difficile car vous devez manipuler manuellement les fichiers journaux et exécuter les utilitaires de base de données d’Exchange Server. Dans ce cas, vous ne pouvez pas récupérer des données complètes.
Que se passe-t-il si les copies actives et passives sont toutes deux endommagées ? Dans de telles situations, vous pouvez utiliser Stellar Repair for Exchange. Ce logiciel de récupération de base de données Exchange peut ouvrir n’importe quelle base de données Exchange Server de n’importe quelle capacité. Vous pouvez naviguer dans la base de données et exporter la base de données récupérée vers PST et d’autres formats de fichiers. Dans ce scénario, vous pouvez créer une nouvelle base de données et exporter le fichier EDB récupéré directement vers une base de données Exchange Server active.
