Incremental-backup size of Fileservers using DFSr

[j.vanledden]

Hi all,

(searching the forum I can’t find a topic with an issue like this; if I’m wrong, let me know)
I've a question about the best way to backup a couple of DFS-servers with Veeam using ( or not) CBT.
One of our customers have an production location with two identical Fileservers using DFSR. The first server is used for client-connections to DFS. The second server is a fallback of the first using DFSR to be up-to-date. Both server VM’s were configured identical.
We’re using Veeam B&R 9.5u4 to backup both servers to on-site backup storage. After that, we replicate (backup as source) them both to an off-site location.
Now for some months this is an active configuration. Recently we noticed some strange result: IncrementalBackup (and replication) of the both Fileservers is different. The backupdata (based on CBT) if the first server is approximately 5 times smaller than the backup of the second one. And of-course at the replication the same. On weekend-backup(no/minimum user activity) the backupsize is small and approximately identical for both servers
We checked lot of possibility’s but can’t find the reason how this can occur:
- Shadow copy turned off.
- A minimum of content in DfsrPrivate subfolders
- Identical partition/volume settings (as blocksize)

Does anyone have an idea how we can find out the reason why there is such a distinction between two identical servers? How coud we solve this?

[Gostev]

Disk fragmentation?

[skrause]

If one server is almost always the "primary" server that users connect to, its DFSR Staging folder is going to have a lot more stuff in it, and a lot of churn as that is where DFS puts a copy of the file during the replication process and then deletes it when the copy is done.

Due to the large amount of changes that occur, we have moved our staging directories to a separate volume that is excluded from the backup job. Losing that data is not really that big of an issue since restoring the DFSR database is not supported by Microsoft, so in the event of a major disaster where we need to restore an entire VM we would need to re-seed/restart replication from scratch anyway.