Veeam Backup and the maintenance of a Reverse Incremental Job

0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares ×

Veeam reverse incremental backups are since their introduction one of the most appreciated features among their users. At the price of an increase in I/O on the backup storage when compared with a traditional incremental backup, it allows for a single full backup file and a long chain of increments, thus offering huge savings on disk space.

However many users ignore that even a Reverse Incremental backups are not “Set and Forget”. Even if a reversed chain can be years long, this kind of usage is not recommended, rather it can lead to several problems.

Let’s suppose we are saving 10 VMs in a single job. Their totale size is 1 Tb, and Veeam thanks to deduplication and compression creates a 500 Gb VBK file. Then after some time 2 of these VMs are deleted, and their total disk usage is lowered to 700 Gb. The supposed size of the new backup would be around 350 Gb, but we see instead the VBK file still is 500 Gb. This happens because there is no way to shrink the VBK file while running a job, unless we run an Active Full backup.

Another problem is fragmentation. Because of the way a Reverse Incremental works, its internal blocks are continuosly swapped and updated by new blocks. This actvity leads over time to an excessive fragmentation of the VBK file, and is useless to defrag the underlying NTFS filesystem for example since the fragmentation is “inside” the VBK itself. Again, the solution is an Active Full backup.

the main concern however is another one. During a restore we could face an error like this one:

Error during restore operation

What’s happened? The VBK file we are restoring from is basically corrupted, and the restore fails.

The error may remain unseen form months, usually because we restore only single files, read from non corrupted blocks inside the backup file. If the corrupted blocks are inside the VBK rather than the reverse files, it could be those blocks are never updated during daily increments, bacuse for example they host the operating system of the Guest OS and they are never updated after the initial installation. So you could realize those blocks are corrupted only after several months, right when you need to read them to do a restore…

To solve this problem, you first need to think that even Reverse Incremental backups need to be managed and maintained, specifically performing regular Active Full backups. This kind of backup creates a new VBK file without reading any of the previous file in the chain, thus creating a new chain. You can run an Active Full manually:

Manually start an Active Full

or even better by configuring the Job to do it in a scheduled way. In the next screen you can see an Active Full configured to run the first saturday of the month, every two months.

Periodic Active Full for a Reverse Incremental job

There is no best practice about how frequently you need to run an Active Full, I usually run them every two months. You need to figure out your best settings, trying to balance between an excessive frequency (that would frustrate the advantages of reverse incremental) and a too long chain (that would increase the risk of having corrupted blocks and bigger VBK files).

Moreover, you need to take into account two essentials facts when introducing Active Full into your schedules:
– backup execution times will obviously increase, so you better schedule active full during non-production times like weekends
– as long as the retention period of the backup jobs is not reached, you will have 2 full VBK files in your backup storage, so you better estimate space usage

Finally, how could we know when the last full backup has been made? You can read all the logs of the jobs inside Veeam, or you can use this quick powershell script I made:


Its output will be something like this (for non european readers, date are dd/mm/yyyy and actual date was 27th March at the time of writing this article):

Script output

You can see two backups where the last full was made almost 5 months before.

A lesson learned: there are NO “set and forget” solutions, NEVER.

0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares ×

One thought on “Veeam Backup and the maintenance of a Reverse Incremental Job

  1. Good article and insight. As a newbie to VEEAM it is extremely helpful to assist me in configuring the best environment I can, thanks!

Comments are closed.