We have customer VM which is around 36 TB in size currently and expected to grow in the near future. The VM hosts DFSR data. Earlier, the VM used to have around 4 TB of DFSR data which we used to backup using a MS-Windows policy with backup selection of shadow copy components for backing up the DFSR data.
Now since the customer had added multiple new vmdks/drives for hosting for DFSR data, I am looking for suggestions for a efficient backup method for backing up the complete VM. Total size of DFSR data is more than 32 TB.
Any suggestions would help and if anyone has encountered such scenario, please advice. The method I can think of right now is to split the backup into multiple policies and backup each DFSR drive in its own policy and possibly take a weekly backup for each drive. Any suggestions for daily backup of the VM?
My backup infra is a one master server and 3 media server ( all redhat) with Ceph storage and AWS Glacier.
How many files are there managed by DFSR?
IMO any instance of DFSR over 5TB is getting too large for any traditional plain client file-system walking backup product to handle.
VM based backup using BLIB and Accelerator is probably your only option - but 36TB in one instance... wow! Personally I think you should break it down in to multiple VMs of smaller DFS instances and then DFSR those smaller instances. This way if one breaks, then all is not lost.
If you cannot break it down into smaller DFS instances, then maybe you need a different hyper-scale storage platform which has embedded incremental forever snapshots with embedded replication HA/DR... because 36 TB, and which is expected to grow more, is, IMO, out-of-scope for DFS/DFSR, and thus also out-of-scope of either traditional or VM style backups.
DFS-R has always been a beast to backup, no matter what method you used.
The official ways is to use:
Shadow Copy Components:\User Data\Distributed File System Replication\DfsrReplicatedFolders
But that method is slow, and fails if to many concurrent streams are used, likewise concurrent backup of c:\Shadow Copy Components and Shadow Copy Components:\User Data\Distributed File System Replication\ also cause backup to fail.
So I am afraid, whatever method you use, there won't really be any good solution.
I think you should warn the user of limitation of the design, and initiate conservation with the customer of alternate soloution, or get the customer to accept backup after "best effort".