When it comes to choosing a backup mode in Veeam Backup & Replication,there is a constant trade-off between space efficiency and I/O efficiency.
Many users select the Forward Mode simply because is the default one. It has a great I/O profile since it requires only 1write I/O per saved block, but on the other end in order to guarantee the consistency of the weekly incremental chain, the oldest full backup needs to stay in place a week after its expiration, thus consuming more disk space then planned by simply counting the retention period.
When they realize the space consumption is too much for their backup storage, they start to evaluate different backup modes, especially the Reversed mode. This mode is great for space efficiency, since no matter how long is the chain there is always only one full backup file and a chain of small increments. However, the trade-off in I/O consumption is pretty heavy: for each saved block, 3 I/O operations are required. If the backup storage is not able to guarantee this level of performances, the final result is a long and slow backup operation.
In order to overcome both limits, and offer an even better solution, Veeam Backup & Replication v8 will have a new backup mode, and it will also be the default one. Derived from the Backup Copy job, it will be probably called “Forward Incremental-Forever Backup” and it will allow as the name implies forever incremental backups like the Reversed mode, but with a different I/O profile that results in faster backups.
The way it works is pretty simple to explain: it starts just like a forward incremental as long as the retention period is not reached. Once the last increment has been created (14 days by default), on the next execution here is what will happen:
– the new increment is written as the newest restore point of the chain (using 1 write I/O as forward incremental)
– VBR realizes there is 1 more restore point than configured
– the oldest file is the full backup, created at the beginning of the chain
– the oldest incremental file is the second oldest file, just 1 day (or 1 execution) newer than the full backup
– the incremental is injected into the full backup, and the superseeded blocks are removed from the full backup. This requires 2 I/O: 1 to read the block from the incremental, and 1 to write it into the full backup
– the incremental file is removed from the chain, and the full backup file is moved in its position
As days go by, this operation is executed every time after a new increment is created.
Thanks to this method, the synthetic operation to create a new full is only limited to the size of the incremental file, instead of the complete size of a full backup file as it would happen in a “forward mode with synthetic fulls”. The overall consumed I/O is the same as the Reversed incremental, but is important “how” the I/O is consumed. During the duration of the backup activity only 1 write I/O is used and so the snapshot of the VM is open for less time than the Reversed incremental; the remaining 2 I/O are used to update the full backup file and most of all after the proper backup operation is already finished; and these 2 I/O are faster anyway to be completed than a Reversed mode.
Last week I presented at the vBrownbag booth at VeeamON conference, and I explained on a whiteboard this new mode. Here is the video, let me know what do you think of the new mode!