Data Domain : Échec de la resynchronisation de la réplication avec l’erreur « Dest MTree is WORM » (5312)

Lors de la resynchronisation de la réplication de structure MTree, le contexte de réplication reste dans un état de connexion et échoue avec l’erreur suivante :

Replication Status
State: Connecting

Error: MREPL ASSOC failed: Dest Mtree is WORM, source requests removal of WORM (5312)

Les logs Data Domain source peuvent contenir :

mtr_update: error: MREPL ASSOC failed: Dest Mtree is WORM, source requests removal of WORM (5312)

Les logs Data Domain de destination peuvent contenir :

mrepl_associate_3_svc: Dest Mtree is WORM, source requests removal of WORM

Indicateurs supplémentaires :

• La resynchronisation de la réplication échoue après la désactivation de la gouvernance du verrouillage de rétention (RLG) sur une ou les deux structures MTree de réplication.
• Les rapports Retention Lock affichent aucun fichier actif verrouillé pour rétention, mais la structure MTree contient toujours des métadonnées liées à WORM.
• Les relations de réplication existantes qui fonctionnaient auparavant échouent après les modifications apportées à la configuration du verrouillage pour conservation.

Ce comportement est inhérent à la conception.

La resynchronisation de réplication n’est pas prise en charge lorsque les MTrees source et cible ne disposent pas des paramètres Data Domain Retention Lock correspondants. Même si Retention Lock Governance a été désactivé, les fichiers précédemment protégés continuent de conserver leurs politiques de rétention jusqu’à l’expiration de leur période de rétention.

Par conséquent :

• La structure MTree de destination peut toujours être traitée comme compatible WORM.
• La source demande la suppression de l’état WORM lors de la resynchronisation.
• L’association de réplication échoue avec error 5312.

Un scénario courant se produit après :

• Les données sont répliquées à partir d’anciens systèmes Data Domain vers des systèmes plus récents.
• Retention Lock Governance est ensuite désactivé sur une ou les deux structures MTree.
• Une tentative est effectuée pour effectuer une resynchronisation de réplication entre les structures MTree migrées.

Pour que la resynchronisation de la réplication réussisse, les structures MTrees source et cible doivent disposer de configurations Data Domain Retention Lock Governance ou Compliance correspondantes.

Actions recommandées :

1. Réactivez Retention Lock Governance sur les structures MTree source et de destination impliquées dans la relation de réplication.
2. Relancez l’opération de resynchronisation de la réplication.
3. Vérifiez que les deux structures MTree signalent le même état Retention Lock avant de lancer la resynchronisation.

Exemple tiré de ce cas :

Source : /data/col1/MtreeExample3 (ND6900)
Destination : /data/col1/mtreeExample (SD6900)

• Activez RLG sur les deux structures MTree et relancez la resynchronisation.
• S’il n’est pas possible d’établir des paramètres de verrouillage de rétention correspondants, créez une nouvelle MTree de destination et initialisez un nouveau contexte de réplication. Dans la plupart des cas, l’initialisation de la réplication se termine plus rapidement que prévu, car les données existantes sur la destination peuvent être exploitées via la déduplication Data Domain.

• La désactivation de Retention Lock Governance affecte uniquement les fichiers nouvellement écrits.
• Les fichiers précédemment protégés conservent leurs attributs de verrouillage jusqu’à l’expiration de la période de rétention configurée.
• Les opérations de resynchronisation sont prises en charge uniquement lorsque les structures MTree source et cible disposent de paramètres de verrouillage de rétention compatibles.
• La présence d’aucun fichier actuellement verrouillé pour rétention dans un rapport ne garantit pas que les exigences de resynchronisation de réplication sont satisfaites.