Backup DFS Replication

Hello ​@SSchmidt  
 

The best practice for backing up a Windows Server with DFS Replication (DFSR) using the Commvault Windows File System Agent is:

• Only back up read-only DFSR members.
• Never back up or restore computers running DFSR on read-write members in a production environment.

Reason

The DFSR database and other Windows multi-master databases do not support snapshots. Backing up or restoring read-write DFSR members can cause replication failures and data inconsistency.

Procedure

1. Identify Read-Only DFSR Members:

• Ensure the server you plan to back up is configured as a read-only DFSR member.

1. Configure the Windows File System Agent:

• Install and configure the agent on the read-only DFSR server.
• Set up your backup jobs as usual.

1. Exclude Read-Write Members:

• Do not configure backups for DFSR servers that are read-write members.

If Restore Is Needed

• If you must restore a DFSR server and it is not read-only, work with Microsoft Support to repair the DFSR database and restore replication functionality.

Reference

For more information, see the Microsoft KB article:

Distributed File System Replication (DFSR) no longer replicates files after restoring a virtualized server's snapshot

and Commvault support article:

https://kb.commvault.com/article/54466

Summary:

Back up only read-only DFSR members with the Windows File System Agent. Never back up or restore read-write DFSR members in production to avoid DFSR replication issues.

Documentation Links

• Commvault Support Article 54466
• Microsoft DFSR Restore KB

Regards,

Kalaivanan. 

Hi,

thanks for your quick reply. u have some more questions :) 

What is regarding VSA Backup is that fine to run VSA Backups from both nodes ? Or should we run crash consistent on primray node and normal vsa backup on readonly node

If i run Windows FIle Backup only on the read only node i have the problem when the windows replication is getting stucked i backup old data. 

Hi ​@SSchmidt 

Apologies for the delay. Please find the below response,
 

1. VSA (Virtualization) Backups on DFSR Nodes

• Backing up both nodes (primary and read-only) with VSA is not recommended for DFSR.
• DFSR is a multi-master database and does not support snapshot-based backup/restore on read-write members.
• Running VSA backups on a read-write (primary) DFSR node can cause DFSR database corruption and replication issues after restore.
• If you must back up with VSA:
• Only back up the read-only DFSR member with VSA.
• Do not run VSA backups on the primary (read-write) DFSR node.

2. Crash Consistent vs. Application Consistent Backups

• Crash Consistent Backups:
  These do not quiesce applications or the DFSR database. While safer than application-consistent for DFSR, restoring a read-write node from a crash-consistent backup can still cause DFSR issues.
• Application Consistent Backups:
  Not supported for DFSR on read-write nodes. Do not use application-consistent VSA backups on DFSR read-write members.

3. Windows File System Agent Backups

• Best Practice:
  Only run Windows File System Agent backups on the read-only DFSR node.
• Limitation:
  If DFS replication is stuck or lagging, the backup on the read-only node may not reflect the latest data from the primary. This is a limitation of the DFSR architecture, not Commvault.

Key Points: 

• Never back up or restore read-write DFSR members in production with VSA or File System Agent.
• If you must restore a DFSR server, only restore read-only members.
• If you back up only the read-only node and replication is stuck, you will back up old data.
  This is expected and can only be resolved by ensuring DFS replication is healthy and up to date.

References:

• Distributed File System Replication (DFSR) no longer replicates files after restoring a virtualized server's snapshot (Microsoft KB)