Backup: Forward or Reverse Incremental - Blog | Novosco

Novosco Blog

Expert opinions and experience from Novosco, one of the UK and Ireland leading managed service providers.

Backup: Forward or Reverse Incremental

Backup: 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 and 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.



What is your personal preference?

Reverse incremental with a weekly active full, for longer than most.

Why then if most others use Forward Incremental?

Times have changed, most platforms and 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.

Stun times are the same using forward or reverse incremental now?

No.  I’m 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 the virtualisation layer snapshots will grow larger and will take longer to remove.  

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, and avoid 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 full will significantly affect restore speed. Do you 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 the repository free space is not monitored (!!?!), the email warnings from Veeam telling you that space was running low were ignored, and for whatever the reason you are now at near zero bytes of 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 backup  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.

Written by Craig Rodgers.

Craig Rodgers is a Technical Architect (Technical Services) with Novosco.  He holds certifications from VMWare, Cisco, EMC, Citrix, Microsoft, Huawei and Zerto.  Primarily working in Infrastructure, Storage, Backups & Networking right down to the OS layer.

Truly passionate about many aspects of IT including Veeam, storage, networking & virtualisation & generally building solutions that work, through technical planning and analysis to contribute towards solution availability.

This blog first appeared on and is used with permission.

‘Move fast and break things' culture coming back t...
FAQs about the migration to Citrix XenApp and XenD...

Blog Categories