Reverse Incremental vs Forward Incremental

[stevehughes]

I know there has been discussion on this in the past, but I'm wanting to gauge the current views on this.

When I first encountered Reverse Incremental I thought it was a very clever idea because (a) it means that the most recent point is always a full and (b) it makes dumping old points very simple.

I like the idea of having the latest point as a full because I would expect that running up an Instant Recovery from it would result in a better performing VM than if it was run from a long forward incremental chain. But I admit I don't know how Veeam handles long chains in the context of restores and IR jobs, and I haven't tested to see if there is actually a performance difference.

I understand that a reverse incremental generates more repository I/O, and so the backup jobs may run slower. The flip-side of this is there is no merge process required at the end of the backup as is required with forward incremental.

Recent comments from Veeam suggest that they don't like to recommend Reverse Incremental, and that best practice is to use Forward Incremental.

Could I get some clarification of the pros and cons and also any reasons why Reverse would not be a recommended practice?

[DGrinev]

Hi Steve,

Reverse incremental is our oldest backup format which works fine.
However, there are a nice benefits you can have with the Forever Forward Incremental:
Major benefit is quicker backup process because of a shorter VM snapshot lifetime (less IO to commit the VM snapshots), thus the Proxy Tasks are freed up more quickly.
Please review this great explanation by Tom about the backup methods. Thanks!

[csydas]

Hey Steve,

From my shop's point of view, the big issue with the Reverse Incremental and Forever Forward Incremental is just that you add in an extra process/step for failure. I'm a Keep It Simple Stupid (KISS) kind of guy, so I like to try to build in simplistic methodology into my planning, and that means periodic backups. For lower priority servers on lesser storages, I go with Synthetic Fulls since at least if it fails to produce the full, there's still the increment for the day, but for my biggest servers, we have a schedule planned around Full Backups weekly on Saturdays.

That works for us, and may not work for you - my guess is that Support probably told you that Reverse Incremental was non-preferred simply because the chain is so dependent on every operation going smoothly. Just from my POV, this is a a bad position to be in - I don't like the idea of relying on a solution where it's great if everything works right. I have tons of hardware errors all the time just due to wear and tear, so for me it's a matter of reality; I'll burn through switches, drives, controllers, etc, and there's just nothing I can do about it. Instead of betting on a set up that is assuming a specific level of reliability, I'd rather just plan for the worst.

[stevehughes]

Thanks for that info.

I thing that I still don't have a handle on is the potential performance drop when restoring from a forever-forward backup set vs a reverse-incremental set. This must be deeply rooted in how the software manages incremental chains.

Take the case where an IR job or a restore needs to be run from the last point in a 300-deep forward chain, vs the last point in a reverse chain. The former has to stitch together a vbk and 299 vibs, while the latter accesses just the vbk file.

Can anyone at Veeam assist with some info regarding how the vib chain is handled during a restore and/or some expected or measured performance comparisons. Sure I could run some comparisons myself but Id rather hear it from the horses mouth.

[Mike Resseler]

Hi Steve,

As Dmitry said, make sure you read up on Tom's post that he included where he states benefits and disadvantages.

In case of an IR job, while booting up the machine from the backup file(s), there will be not that much disadvantage compared to forever-forward. If you read here (at least if you are using VMware, Hyper-V is a bit different) https://helpcenter.veeam.com/docs/backu ... tml?ver=95 you will see that we do not "touch" those files in order to keep the backup safe. Now obviously it means while running as IR, the program will need to get information from different files so at that moment you will see more IO and need more resources but when the backup storage is designed well, you can have great results.

I do agree (personal note) that I don't want to work with a 300-deep forward chain. Now that we have ReFS support, I prefer to use this method with a synthetic every week or so (depending on how important the workload is and what (potentially) my SLA is for that workload).

I know I didn't answer your question around performance comparisons (I don't have those, maybe someone else does) but I think the most important thing you need to consider is what disadvantage will have the most weight for you, and then use the method you prefer, (and if it is forward incremental, look at synthetic + ReFS)

[rbance67]

Reverse Incremental works well. I would not use this method for large VMs though, or ones with a higher rate of change. The real advantage from my perspective is the last backup is effectively a full.

[RubinCompServ]

Perhaps it's just me, but I've found that doing a Forward Incremental, creating daily Synthetic Fulls, and turning previous Incrementals into Rollbacks gives me the performance of a Forward Incremental but the structure of a Reverse Incremental.

[foggy]

Hi David, indeed the final chain structure is the same, however, the total I/O load on the storage is actually higher. Part of the I/O is postponed for the post-processing stage though so the snapshot is released faster.

[RubinCompServ]

@foggy, That is true and a very good point, but I find the trade-off to be worth it for a shorter snapshot time and quicker recovery time.