Reverse vs daily transform?

[caustic386]

It is accurate to say that reverse incremental would behave identically to creating a synthetic full (with transform) every day?

We are experiencing very long rollup times by only running the transform once a week, which are currently failing after 48 hours. This has happened twice, and I just read that there is a patch available for this issue but 48 hours is still too long, so I'm considering changing over to reverse differential.

This is for WAN backup, 10Mb connection with a 450GB VBK. When a transform fails (ours has failed twice), is it necessary to re-run a full?

[foggy]

Steve, yes, reverse incremental is identical to the daily synthetic full with transform.

It is not necessary to rerun a full in case of failed transform if you are sure that the synthetic full is completed correctly.

Btw, what version of Veeam B&R are you on and what kind of target do you use?

[Vitaliy S.]

If you take a look at these modes from IOPs perspective, then there is a difference, here is a short summary on that:

- active full = 1x I/O on target (write for each block)
- synthetic full for incremental backup mode = 2x I/O on target (read + write for each block)
- synthetic full for reversed incremental backup mode (w/rollbacks) = 3x I/O on target (write + read + write for each block)
- synthetic full for incremental backup mode with transform (w/rollbacks) = 4x I/O on target (read + write + read + write for each block)

[caustic386]

We are using v6 patch2, with 3x sata 5400rpm 1tb drives as a target. Target storage is obviously an issue, but the last post is interesting. 25% less io with reverse incremental? Does that come at the expense of increased network activity?

[Vitaliy S.]

No, it just needs one read operation less than daily synthetic with transform. Should more info be required please take a look at our sticky F.A.Q. and our User Guide (starting from page 26). Thanks!

[tsightler]

Honestly, I recommend the "incremental with daily transform" quite often for customers who are experiencing long weekly transforms. That being said, one thing to look for is for servers that are "blowing up" your transform. In most cases file and application servers create very small incremental files, thus "rolling them up" is not too bad, however, for transactional servers like Exchange and SQL, the incremental can sometimes be as big as 20-30% or more of the full backup. I've seen cases where a 500GB Exchange generates 100GB of incremental data every day. This can take a huge amount of time to roll up.

Performing an incremental and daily transform has the advantage that the backup happens much faster, thus the VM snapshot is held for less time. The transform may still take quite some time, but this is all on the target storage. If you're spending 30 hours performing a weekly rollup, then you may still spend 4-5 hours every day working on the transform, but that's typically OK.

[caustic386]

We do have 1-2 culprits. Exchange being one of them, the other can generate 80GB of changes on a 150GB VMDK, and I think that's what's hitting us hard when the transform day rolls around. I will upgrade the target storage and setup a daily transform; seems to be my best option. Thanks!

[tsightler]

Another option that I've used successfully when there are just a couple of servers that are the culprit is to simply split those servers into their own job using incremental mode with scheduled "active" full backups. This does of course provide more impact on the source storage, and since it's really just another full backup, and it also requires more space on the target, but since is usually only a small subset of servers, it's sometimes a good trade. Just another thought.