Data Domain: Replication Resync Fails with "Dest Mtree is WORM" Error (5312)

During MTree replication resync, the replication context remains in a connecting state and fails with the following error:
Replication Status

State: Connecting

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

Source Data Domain logs may contain:

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

Destination Data Domain logs may contain:

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

Additional indicators:

• Replication resync fails after Retention Lock Governance (RLG) was disabled on one or both replication MTrees.
• Retention Lock reports show no active retention-locked files, but the MTree still contains WORM-related metadata.
• Existing replication relationships that previously worked fail after changes to Retention Lock configuration.

This behavior is by design.

Replication resync is not supported when the source and destination MTrees do not have matching DD Retention Lock settings. Even if Retention Lock Governance has been disabled, files that were previously protected continue to retain their retention policies until their retention periods expire.

As a result:

• The destination MTree can still be treated as WORM-enabled.
• The source requests removal of the WORM state during resync.
• The replication association fails with error 5312.

A common scenario occurs after:

• Data is replicated from older Data Domain systems to newer systems.
• Retention Lock Governance is later disabled on one or both MTrees.
• An attempt is made to perform a replication resync between the migrated MTrees.

For replication resync to succeed, both the source and destination MTrees must have matching DD Retention Lock Governance or Compliance configurations.
Recommended actions:

1. Re-enable Retention Lock Governance on both source and destination MTrees involved in the replication relationship.
2. Retry the replication resync operation.
3. Verify that both MTrees report the same Retention Lock status before initiating resync.

Example from this case:

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

• Enable RLG on both MTrees and retry the resync.
• If matching Retention Lock settings cannot be established, create a new destination MTree and initialize a new replication context. In most cases, replication initialization completes faster than expected because existing data on the destination can be leveraged through Data Domain deduplication.

• Disabling Retention Lock Governance only affects newly written files.
• Previously protected files continue to retain their lock attributes until the configured retention period expires.
• Resync operations are supported only when both source and destination MTrees have compatible Retention Lock settings.
• The presence of no currently retention-locked files in a report does not guarantee that replication resync requirements are satisfied.