Guidance on best Backup Method based upon %% Change?

[virtualwatts]

Howdy,

Has Veeam or anyone else created an analysis matrix for when to use each backup methodology based upon quantity and frequency of change in the VMDK? What I am seeking are the tipping points based upon percent change of blocks in a vmdk for when CBT, forward incremental, reverse incremental and full backups are best.

We use forward incrementals (with CBT) for most of our jobs but I am considering a change for some of our vmdk only backups based upon how much work Veeam must do to constantly reconcile the VBK and VRB files.

For example:
Say I have a 300GB vmdk that has lots of daily add/delete activity of large files (30MB - 1.5GB)
The result at backup might be:
20% blocks changed nightly
30% blocks changed nightly
40% etc...

When does reverse incremental become too much work to manage all the change?
At some point the overhead of managing all the VIB, VBK and VRB for forward incremental exceeds the cost of just copying the file?
When does CBT become sub-optimal? (no, really, on a Windows server it happens quickly....)

I did a couple of queries but didn't see any threads, if you know of one then please point me...

Thanks
Rick

[Gostev]

Hi Rick, at 33% of changed blocks, reversed incremental run will start taking more time than an active full run, so I guess this can be considered a tipping point. The math is pretty simple here, on a high level reverse incremental run requires 3 I/O operations per changed block on target (R+W+W). Regular incremental run requires 1 I/O operation per changed block (W). Thanks.

[virtualwatts]

Perfrect Gostev, thanks. That makes sense.

Then what about forward incremental and CBT? Any thoughts there?

We are implementing steps across the board to stop deleting and instead do zero-byte wiping in our jobs. Doesn't change number of changed blocks but does allow for dedupe/compression. That should reduce the longer-term retention costs of large transitive files.

[Gostev]

With forward increments, CBT only becomes suboptimal at 100% of changed blocks so really this one has to be always enabled.

Please note that zero-byte wiping does change number of changed blocks (as you physically update contents of all blocks). In fact, it will "change" every block it processes (from perspective of VMware CBT), even if it was already zeroed. On the other hand, simply deleting a file does not change the contents of disk blocks backing the file (in NTFS), and thus does not change number of changed blocks.

[virtualwatts]

Please note that zero-byte wiping does change number of changed blocks (as you physically update contents of all blocks). In fact, it will "change" every block it processes (from perspective of VMware CBT), even if it was already zeroed. On the other hand, simply deleting a file does not change the contents of disk blocks backing the file (in NTFS), and thus does not change number of changed blocks.

Well, kinda. That is one aspect of the block dynamics primarily suited for static systems like file servers or web servers. Couple of other key elements are that those dirty blocks may not compress, the Windows OS allows limited control over their reuse and they are kept in Veeam for eternity during the VIB/VBK/VBR dance. For example, if you write to a file and then in the same day compress or encrypt that file, deleting the original. If you do not zero byte the original file Veeam happily backs those blocks up as well, and integrates them into the VBK/VBR files even though they are worthless. Same for Windows temp space, BI and Reporting servers and App Server output or working space. Lots of intraday files. Like I said, either way you get a changed block but with zero bytes you get higher compression/dedupe. Not as much an issue for forward incremental, but if you use reverse incremental or multi-day synth then those dirty but useless blocks have to be integrated into the main VBK inflating the size of the VBK, increasing CPU on Veeam server and pro-longing the backup job.

Just a different use case.