VBR + DataDomain Immuability + Mtree Replication

Hi ​@Stabz ,

Some colloeagues of mine are building this construct quite often. And they told me that retention lock is preserved within mtree-replication.

Here is what i found out online:

MTree Replication and Retention Lock Integration:

• Replication of Retention-Locked MTrees:

  MTree replication can be used to replicate data from a Retention Locked MTree to another Data Domain system. 

• Retention Lock Propagation:

  If the destination MTree is also Retention Lock enabled, the retention lock settings (including minimum and maximum retention periods) are replicated along with the data. 

• Cyber Recovery:

  MTree replication plays a crucial role in Cyber Recovery solutions by replicating immutable backups to a secure vault for isolation and protection against ransomware. 

• Fast Copy:

  If a Retention Locked file is fast copied to another MTree, the retention lock is maintained if the destination MTree is also Retention Lock enabled. 

In essence: Data Domain MTree replication and Retention Lock work together to provide a robust data protection strategy. Retention Lock ensures the integrity of critical data by preventing modification or deletion, while MTree replication provides a mechanism to create secure, offsite copies for disaster recovery and long-term retention, including in isolated environments like Cyber Recovery vaults. 

there also should be corresponding KB-Article. I´ll post it as soon i find it. 

Regards

Chalid

Thank you for your feedback and the research you’ve done. I came across the same information in the documentation, but I’d really appreciate a confirmation.

Since immutability is applied by Veeam on the primary Data Domain, I want to make sure that this setting doesn’t cause files to become stuck or undeletable on the secondary DD after replication.

Thanks again for your help!

With storage appliances like DataDomain and Storeonce, Veeam doesn’t manage the immutability, it just requests it based on what you configure in Veeam and the storage itself handles the immutability. 

As currently Veeam does not officially support mtree replication, I’m doubtful this was tested on the Veeam side. 

So it would be best to just ask Dell what happens to a file with retention lock when mtree replication is performed.

I did find this FAQ, but I’ve not had a lot of DataDomain management experience so please double-check the information yourself:

https://www.dell.com/support/kbdoc/en-us/000079803/data-domain-retention-lock-frequently-asked-questions-faq

Can replication still be used against MTrees which have retention lock enabled?

Yes, retention locked MTrees or files can be replicated using various replication topologies:     

• Directory replication - only supported for files using governance mode - does not replicate minimum and maximum retention periods to the destination system.
• MTree replication - can be used for either governance or compliance mode data and does replicate minimum and maximum retention periods to the destination system.
• Collection replication - can be used for either governance or compliance mode data and does replicate minimum and maximum retention periods to the destination system.

Note: For retention locks to be preserved on destination systems:

• Both the source and destination systems must have corresponding retention lock licenses that are installed.
• If replicating a RLC enabled Mtree then both source and destination DDs must have RLC configured or the next error will be received:
  "A compliance retention-locked MTree cannot be replicated to a destination that is not enabled for compliance retention-lock."
• MTree replication contexts must have 'Replication propagate-retention-lock' set to Enabled.
• For files replicated by directory replication, the corresponding MTrees minimum and maximum retention periods must be manually set on the destination system.

 

Are there any other restrictions when replicating retention locked files?

Yes, resyncs of replication contexts (that is trying to reestablish a previously configured but broken context) where retention locked data is used to can fail.
 Note:

• If MTree replication is used, and the destination MTree contains retention-locked files which do not exist on the source, a resync fails.
• If directory replication is used to and the destination has a retention lock that is enabled but the source does not, then a resync fails.

 

Note: When using MTree replication, a resync succeeds in the following scenarios, if the destination MTree does not contain retention-locked files not present on the source DDR:

• The source MTree does not have retention lock enabled, but the destination does.
• The destination MTree does not have retention lock enabled, but the source does.

It is also not possible to enable retention lock compliance mode on an MTree which is already a member of an MTree replication context. In this scenario:

• The MTree replication context should be broken on both source and destination systems:

# replication break mtree://[destination system]/data/col1/[mtree]

• A new MTree replication context should be created on both source and destination systems:

# replication add source mtree://[source system]/data/col1/[mtree] destination mtree://[destination system/data/col1/[mtree]

• Retention lock compliance mode should be enabled on the source system:

# mtree retention-lock enable mode compliance mtree [mtree]

• The newly created replication context should be resynced on the source system:

# replication resync mtree://[destination system/data/col1/[mtree]