Sanity check - ReFS and Backup Copy "Read entire restore point..."

[Trin]

I'm just after some confirmation that my understanding of the Backup copy job tick box; "Read the entire restore point from source backup instead of synthesizing it from increments" improves the process of "Merging backup files" but not the "Creating GFS restore point" operation...

Merging backup files - data from the last regular backup job full .vbk is read from its repository and written to the backup copy repository (in our case we have separate repositories for each), rather than the backup copy repository creating it's own full backup from its own files; reading and writing on the same repository (high iops).

ReFS - If our repository is not ReFS but is NTFS, enabling the tick box will mitigate the slower operation of NTFS somewhat, by eliminating the need for the synthetic copy process; reading and writing on the same repository (a process improved by ReFS).

Creating GFS restore point - the weekly/monthly .vbk is synthesized/cloned from an existing .vbk from the same backup copy job (on the same repository) so the tick box would not help here but ReFS would.

Have I got all that right??

Many thanks!

[tdewin]

GFS Synthetic creation on ReFS will definitly done by using pointers and will save space and time. Don't forget to format 64KB and install the latest updates!

If you enable the checkbox under the retention policy "Read entire restore point.." , you are basically activating active full for backup copy job. Just like Active Fulls for primary job, a new VBK will be created and all data will be read from the source repository meaning no connection with the previous points on the target. It should still go pretty quick because it is a sequential load but the downside is that everything has to cross the network and because there is no relationship with the previous points, it will consume the complete space on disk

[Trin]

Thanks tdewin.

I'm not sure whether I should be ticking that box now, or not. I was prompted to post because one of our backup copy jobs had taken nearly 60 hours to process, mainly the merge part at the end. The current weekly .vbk files are approx 2TB and the latest running .vbk is 1.8 (the two .vibs we have are 100GB and less). My assumption was that the read/write process of the merging was the cause of the problem so ticking the box would improve that but now I'm not so sure.

Does Veeam support offer some sort of health check or config check to make sure all these little things are set up for the best performance of our infrastructure?

[foggy]

Yes, you can contact support for assistance in checking your setup, but in case merge is the slowest stage of your job, I would definitely try enabling the 'Read from source" check box.