REPO I/O Limit and Fast Clone

[lkwjochen]

Hiho!

I've observed that when I set an I/O limit on a backup repo with a Fast Clone capable file system the maintenance setting "Defragment and compact full backup file" of a Backup Copy Job takes very much longer than without having an I/O limit. I've tested it a few times on XFS and ReFS repos and it's reproduceable.

After the copy part from the primary repo has finished there's no noticable I/O on the target repo during the "Defragment and compact full backup file" step. But it still takes (in my case) hours to complete this step. Without the I/O limit this step only takes a few minutes.

It looks like Veeam doesn't take into account that Fast Clone doesn't really shuffle data from and to the repo file system since it's mainly a rearrangement of file system pointers (simplified).

Or have I misunderstood this feature?

Regards

[david.domask]

Hi lkwjochen,

I don't think you've misunderstood anything really, for Forever Forward Incremental retention, usually the recommendation is to enable Defragment and Compact the full; however, fast-clone does change this a bit and there have been discussions previously on the benefit of defrag with fast clone. While the topic is discussion file system defragmentation, the same applies to this operation.

You are correct in how Fast Clone functions, and that's kind of why I suspect that defrag and compact full aren't super necessary here -- in the past it made a lot of sense before we did True PerVM backups (all machines in a job were in a single large backup file, with lots of "dead" data blocks being left as machines were added/removed from the job), and Compact Full solved this dead space issue as well as performance issues with restore operations using such a fragmented backup file.

Really, I would advise enable Synthetic Fulls for the job as with Fast Clone, the Synthetic Fulls are "space-less", and you avoid the problem of backups being constantly merged into the full backup, and you don't really have to worry about the IO controls' impact on the compact full.

[lkwjochen]

Hi David,

thanks for the answer and clarification of the benefit of Defragment and Compact nowadays. But I am a little bit confused about the synthetic backup fature since I don't have an option for this with Backup Copy Jobs, only with VM Backup Jobs (and I'm already using it there since years, of course).

[david.domask]

You're very welcome for the advice so far.

For your question, the confusion is understandable as by default, Backup Copy jobs use Synthetic Fulls to create GFS restore points. I would advise a single weekly point can help here. You can configure the backup copy to perform "Active Fulls", but that would not benefit from fast clone.

So in essence to do this you'd just enable GFS.

[lkwjochen]

Ah, ok. Thank you very much.