2017, we hardly knew ye! The year came and went in a flash, with many of us still wishing we had more time to do the things we had on our list. That is what the New Year is for right? What better time to refresh, re-organize and revitalize IT to-dos than at the start of the year!
If you’ve added to the data or VM count that you are backing up on site, there is a possibility you may have outgrown your current backup strategy. Perhaps your backups are now exceeding their acceptable backup window, or are running out of storage to keep them on. First things first: Before you start throwing money at the problem, make sure to locate the current holes in your strategy. Is our backup server resource constrained and can no longer process the backups in time? Or perhaps the repository is the bottleneck?
Before you invest in server or storage resources, consider that a brand new backup method might be a better fit for your current requirements. Our trusted partner Veeam has a very nice and detailed breakdown of different backup configurations on their expert exchange, which I have summarized below.
The table below provides a general overview of Veeam-supported backup methods and their I/O impact on source and destination storage:
Method |
I/O impact |
| Forward incremental | 1x write I/O for incremental backup size |
| Forward incremental, active full | 1x write I/O for total full backup size |
| Forward incremental, transform | 2x I/O (1x read, 1x write) for incremental backup size |
| Forward incremental, synthetic full | 2x I/O (1x read, 1x write) for entire backup chain |
| Reversed incremental | 3x I/O (1x read, 2x write) for incremental backup size |
| Synthetic full with transform to rollbacks | 4x I/O (2x read, 2x write) for entire backup chain |
Forward Incremental Backups
The forward incremental backup method generally works well with all storage devices, although it requires more storage space than other backup methods due to the fact that it requires the creation of periodic full backups.
Active Full Backups
When creating an active full, the I/O pattern on the backup storage is mainly sequential writes, which generally provides good performance for most storage solutions. However, all the data (not just the changes) has to be copied from the production storage, and this will increase the duration of the backup activity and the time a VM snapshot remains open.
Use |
Don’t Use |
| Recommended for deduplication appliances that use SMB or NFS protocols. | When backup window does not allow enough time for re-reading all of the source VM data. |
| On storage systems that use software or non-caching RAID hardware such as many low-end NAS devices. | For large or performance sensitive VMs where re-reading the data can have a negative impact on the VMs performance. |
Synthetic Full
Due to the way synthetic full works, having many smaller backups jobs with fewer VMs will allow for faster synthetic full operations. Keep this in mind when setting up jobs that will use this method or choose to use Per VM Backup Files.
Use |
Don’t Use |
| When repository storage uses fast disks with caching RAID controllers and large stripes. | Small NAS boxes with limited spindles that depend on software RAID. |
| Deduplication appliances that support offloading synthetic operations. | Deduplication appliances that use SMB or NFS protocols. |
Forever Forward Incremental
The primary advantage of using forever forward incremental backup method is space savings. However, the tradeoff is the required resources for the merge process. The merge process may take a considerable amount of time, depending on the amount of incremental changes that the job has to process. The advantage is that the merge process impacts only the target storage.
Use |
Don’t Use |
| Repositories with good performance. | Smaller backup repositories or NAS devices with limited spindles and cache. |
| Ideal for VMs with low change rate. | Jobs with significant change rate may take a long time to merge. |
Reverse Incremental
This method provides space-efficient backup, as there is only one full backup to store. It also facilitates retention, since removing old restore points is simply a matter of deleting old VRB files.
The disadvantage is that creation of rollback files occurs during the backup process itself, which results in higher I/O load on the target storage and can slow down the backup process.
Also, over time the in-place injection of new blocks into the full file causes fragmentation of the VBK file. This can be partially fixed by using compact operations.
Use |
Don’t Use |
| When repository storage uses fast disk with caching RAID controllers and large stripe sizes | Small NAS boxes with limited I/O performance |
| VMs with low change rate | Deduplication appliances due to random I/O pattern |
| High change rate VMs, as VM snapshot may be open for a long time |
Updated: January 2019
