Forward or Reverse Incremental?
Petrol vs Diesel? Apples & Oranges? Is it a matter of preference? Moving forward seems logical? Is moving backwards better in some cases? I can think of a few real-world examples that fit both cases but in the sense of Veeam backups, which one is better?
Better is a very general term…
I suppose it is so let’s weigh things up at a more granular level. Veeam have a mountain of reference data on the functional differences, performance & best practices for each type of backup. A lot of the time it comes back to stun settings on VM snapshot removal and backup window about the additional I/O overhead in creating a reverse incremental on the target backup repository. These are both common denominators that can be easily compared as VM X shows Y and Z using Forward vs Reverse. There are other factors that need to be considered properly to compare the two, that I seldom see referenced.
Manageability?
Yes.
What is your personal preference?
Reverse incremental with a weekly active full, for longer than most.
Why then if most others use Forward Incremental?
These days times have changed, most platforms & backup targets have a cache layer that takes the initial I/O hit, from SSD cache drives in a NAS or SAN to multiple enterprise grade NVMe drives in a physical backup server or hardware deduplication appliance, RAM is awesome for this as well.
Why more RAM?
More RAM makes things smoother, faster and stable due to reducing stress on numerous systems such as disk, network and storage using caching, 100% fact. Pity the prices for DDR-4 in 2017 have gone up, thankfully Samsung have decided to increase output significantly along with others such as SK Hynix and Micron which may bode well for better prices, especially from 2019 onwards, last year’s oversupply vs this year’s shortage may fare better for those without the buying power of a Worldwide Cloud Service Provider, all of whom have been paying a lot more this year to ensure their continued hardware landscape growth.
Stun times are the same using forward or reverse incremental now?
No. Not going to misrepresent here, reverse incremental takes longer to back up owing to the fact more IOPS must take place on the target repository, as such it is a fact that it takes longer and as such the virtualisation layer snapshots will grow larger and as such will take longer to remove and that’s a fact. However, if you are looking at a new backup system, look at your current snapshot removal times, I am almost 100% certain that any new backup system you deploy will have significantly reduced snapshot removal times using reverse incremental backups vs your old forward incremental backups, if they do not, let me know because something is drastically wrong with the solution you are deploying. Feel free to create some test VMs with some equal change data via a robocopy script or the likes from file servers or whatever other mechanism you are comfortable with, just do not create a second backup of a production VM, backup once, copy many, avoids CBT issues in the real world. Daily I see snapshot removal times in the low single digit seconds using reverse incremental though.
So why bother to take longer to back them up?
90% of the time, what backup are you restoring? The most recent backup? Probably, especially in a disaster scenario, you will be restoring the last backup and having that backup available as a full will significantly affect restore speed, need a lower RTO? Having to restore through incremental backup chains has an overhead, the same can be said for older reverse incremental chains.
You mentioned manageability?
I did, so you are running a backup system, something happens that causes an abnormal amount of changed data, worst case you run all flash systems and you get a ransomware infection that does not get caught. So now you have huge amounts of changed data that needs to be backed up as far as any backup system knows from CBT data. If your repository fills up for this or any other reason, what are your options in a forward incremental job? Maybe you are insane and the repository free space is not monitored, the email warnings from Veeam telling you that space was running low were ignored for whatever the reason, you are now at near zero bytes free space on your backup repository. What do you do with a forward incremental backup target repository to get backups working again quickly for whatever reason?
Add more space?
For free? I’d love a few of those storage systems. What if you used some of the un-provisioned space last time and you don’t have enough? Using reverse incremental you can remove older parts of the backup chain and retain the ability to perform a full restore and not interrupt the backup chain, because it grows backwards.
The process is simple, ensure no jobs are active, put the repository into maintenance mode, remove older retention point files to achieve the desired amount of free space, re-scan the repository, check the backups for the job and forget all unavailable restore points.
Veeam help link?
https://helpcenter.veeam.com/docs/backup/hyperv/remove_missing_point.html?ver=95