can i exclude the garbage collector from the backup

[thethommyy]

Hello,

can i exclude the garbage collector from the veeam reverse-incremental backup ?
We have massive runtime problems and very large repository files.
As first we had the garbage collection only on Saturdays. after this we had runtimes from 35 hours per backupjob and repository-files from 1TB and higher.
Because we have a retetion time of 28 days the complete resositorie-files are from 10TB till 32TB.
Now , the garbage collection is every day, but the runtimes if the jobs ist still high and the repository-files are around 500GB per day.
I have already tried different settings in Veeam-Backup, but no success.
Does somebody has any idea what we can do ?

Thank you very much !

Thomas

[Gostev]

Hello, what exactly do you mean by "garbage collector"?

[thethommyy]

Hello,
I understand what "Garbage Collection (GC) is one of the regularly scheduled jobs used by Windows Server Deduplication to maintain the optimized data. GC is responsible for reclaiming disk space by removing unnecessary chunks that are no longer being referenced by files that have been recently modified or deleted."
We start GC every evening for the fileserver we have and Veeam thinks what many data has been changed and starts backups for the Garbage Collection files. Before this we have started GC once a week, but the results was the same - large repository files.....
Thomas

[Gostev]

Veeam does not "backup Garbage Collection files" in principle, since we do image-level backups. And during incremental runs, we backup all disk blocks that had its content changed.

While Veeam does provide an option of excluding folders from image-level backups, Windows dedupe chunk store is the single folder, so you obviously can't exclude it from backup.

The only thing you can potentially improve is backup performance. You should be able to get faster backups by scheduling the backup job to do an Active Full following weekly garbage collection run. This may be faster than an incremental run against large amount of changed blocks, due to Active Full being a sequential read operation (vs. random reads of incremental backup).

[thethommyy]

Thank you !
Thomas