Reverse and Forward incremental merges

[B.F.]

Greetings,

I was thinking about our current backup setup for one of our file servers. It is doing a forward forever incremental at the moment. Since there is merging happening with the oldest .vib to the .vbk based on the retention policy, would that be the same type of process if one were to choose a reverse incremental where it merges the .vrb to to the .vbk.?

If the process is the the same or the time it takes is similar, I'm wondering if reverse might be a better solution for us.

Thanks!

[Shestakov]

Hello,
Yes, it's going to take about same time.

[foggy]

The backup itself might require similar time, however, keep in mind that with reversed incremental mode, snapshots are kept for the entire job duration, not just during the actual backup phase as with forever forward, where merge is done after committing the snapshot, decreasing the total job run time. Here's a good explanation of how the modes differ.

[B.F.]

Good info about the 1 + 2 IOPS for forward versus 3 IOPS on Reverse! Curious, why is Reverse designed that way? Couldn't the reverse merge process be done in a similar manner (1 + 2 IOPS) where it's incremental is first copied down and then merged to the vbk in post?

Thanks

[Shestakov]

Reverse incremental need to create an increment, make it full backup and make an increment out of former full backup and then delete the oldest increment. While forever forward just creates an increment and then merges the 2 oldest points into 1 full.

[B.F.]

Wow, that seems like a lot of shuffling of bits! Would this work for Reverse Incremental process?

VBK is the newest followed by progressively older .VRB
An incremental is taken. Once completed, that incremental is the latest file.
Post process time
Merge the latest incremental into the .VBK which creates a fresh full.
That latest incremental then becomes the newest incremental in the .VRB chain
Oldest .VRB gets deleted

Technically the newest .VRB is not needed at that point in time anymore since it's in the .VBK. However, it is needed after the following backup for retention.

I'm prepared for ya'll to point out why this is not possible, won't work, or a bad idea.

Thanks

[foggy]

This would require even more IOPS during the post-processing stage - 4 of them actually (2 to read and write blocks from the newest increment into full and 2 more to read and write blocks from full to make a "previous" restore point). And this is actually what is done in case you select synthetic fulls with transformation.

[B.F.]

Ahh, I think got it now. I didn't realize it was really necessary to have to create a new vrb from what was on the vbk if you already had the previous vrb. But I see now why it is.

Thanks!