Backing up DFSR servers - Support & Best Practices

[trystan.mann]

Hi,

I'm working with a customer implementing DFS in their organisation migrating from traditional file shares, now they are looking to use DFS-R to enable high availability of file services.
Reading various articles and searching through the Veeam documentation it isn't abundantly clear of the supportability by Veeam and or by Microsoft a previous Article veeam-backup-replication-f2/snapshot-of ... 65-15.html references a Microsoft KB http://support.microsoft.com/kb/2517913 that says :-
"Snapshots are not supported by the DFSR database or any other Windows multi-master databases. This lack of snapshot support includes all virtualization vendors and products. DFSR does not implement USN rollback quarantine protection like Active Directory Domain Services. Under no circumstances should you create or restore snapshots of computers running DFSR on read-write members in a production environment. Snapshot restore is only supported for read-only members as their version vector is not tracked on partners and an USN rollback cannot happen."

While I know Veeam cannot answer for Microsoft I would like to know if it is indeed supported by Veeam and what if any are the best practices for backing up a DFS-R Virtual Machine.

Many Thanks

[trystan.mann]

Ultimately looking at other posts around 1 supported solution would be to back up the VM and the Data on the volumes from a read-only replica of the data but of course I'd then be looking at having 2 read write servers then have a 3rd read only and then take backups of that would mean I'd need at least 4 times the original data set size storage (without any form of deduplication).
1 Terabyte shared data Server1 (Read-Write)
1 Terabyte Replicated to Server2 (Read-Write)
1 Terabyte Replicated to Server3 (Read-only)
1 Terabyte of Available Space on VBServer1

[DaveWatkins]

To me I think the wording there is wrong. Not supporting USN rollback only means you should never revert to a snapshot. Creating a snapshot for the purposes of backup and then deleting it should be fine.

The problem will be if you restore that server while the other DFS-R members are still active you'll corrupt the shares. But if you had other members still active you'd build a new server and create a new member, not restore an old member that's failed.

To me backups of a DFS member are solely for catastrophic failure when you lose the entire environment, or to do item level restore. Neither of those will affect DFS at all

[skrause]

I have been backing up DFSR servers for several years here with no big gotchas. No "only backup a read only copy" or anything like that. We do use AAIP so that we can leverage VSS and file system indexing.

Of course, like Dave said, the backup is for a situation where "we lost it all across the whole DFS group" or when I need to do file level restores of deleted files so having the DFS database being corrupted is something I am not particularly worried about. If I lose a single node, I am probably going to just spin up a new member server and re-seed it from a "working" copy rather than try and restore it because once the initial seeding is complete it is difficult to control which server is authoritative in terms of what files are "current".

In a situation where I am so far down the disaster rabbit hole that I am doing a full VM restore, the additional few minutes work to dismantle and recreate my DFSR group and have it re-seed everything is not a game breaker.

[rogerdu]

I too would like to get a definitive answer on this. We're putting Veeam into an environment where the file servers are over 20 TB total footprint and have the ability to do cross site replication. If the replicated image is not going to work, I need to be able to tell the customer this so they can decide whether to have a member server at each site...

Thanks!

[skrause]

If having a member server in the target site is feasible, that would be the ideal solution for the DR site.

As far as backing up the DFS-R servers goes, I have been doing it on multiple DFS-R servers/namespaces for years and have had no issues with it breaking DFS. We do file level restores periodically. We do realize that if we do have a case where we need to do a full restore, we are going to have had such a major outage that re-creating DFS-R groups is likely to be one of the many things we will have to reconfigure. (We have DFS-R replicas in our DR site.)

Since the limitation is on Microsoft's end, there is not a lot Veeam can do about it.