Forward Incremental backups offer the advantage that they perform only sequential writes to the target repository meaning that performance is significantly higher than reverse incremental backups. However, this backup mode does come with costs, primarily in the requirement to schedule periodic full backups. These backups will take additional time to create and, based on the method, addition space on the target repository.
There are three options for creating new full backups:
•Synthetic Full — this method uses the most recent full backup, and any incremental backups created since then, and builds a new full backup using this data. This requires space for a new full backup, and random I/O on the target repository and can take a long time to process.
•Synthetic Full w/Transform — this method uses the most recent full backup, and any incremental backups created since then, and builds a new full backup using this data, while converting the incremental backups to reverse incremental files. This requires only a small amount of additional space on the target repository, but usage a large amount of random I/O and can take a very long time to process
•Active Full — this method simply runs a new full backup by reading all data from the source VMs. This requires I/O on the source storage, enough space to store a new full backup and sequential write I/O on the target repository.
When thinking about the cost of Forward Incremental, the additional disk space requirement can be significant. With a typical job that keeps 30 daily restore points the additional disk space can be as much as 4x that of a similarly configured reverse incremental job.
You can compensate for limited target I/O by making use of incremental backups, which perform streaming write I/O and thus are not as affected by the limited IOPs available from the target storage. However, keep in mind that relative to reverse incremental, forward incremental can require significantly more space for similar retention periods, like shown in the example below.
ACME Corp needed to back up 100VMs, with a total size of 10TB (an average of 100GB per VM). They decided to buy a simple NAS storage device with 6x2TB SATA drives giving them ~10TB of usable RAID5 storage for backups but real world IOPs topped out around 300-350IOPs.
After compression and deduplication, the original .VBK file was 2.5TB, and nightly backups were averaging around 100GB each. This meant that, using reverse incremental, keeping 30 days of backups would only require approximately 5.5TB of space, easily small enough to fit on the target storage.
Unfortunately, because of the slow disks, the backups were taking ~6-8 hours every night which was longer than the desired backup window.
Because of the slow backups, ACME decided to switch to incremental backups. This provided a significant boost in performance, shrinking the backup windows to 2-3 hours each night. However, they now need to run occasional full backup. Keeping 30 days of retention with a full backup once a week requires far more space, since each weekly backup is 2.5TB.
To keep 30 days of retention requires 5 weeks of full backups, which is 12.5TB, plus 25 days of incremental backups, at 100GB/day required more than 15TB of disk space.
ACME’s administrators considered the possibility of running full backups only monthly, but this still meant that, to keep 30 days of retention, they would need enough space for at least 3 full backups, and up to 58 days of incrementals, since the oldest full could not be deleted until there was a new backup chain of at least 30 days. This would require more than 13TB of space.
It’s likely that ACME Corp would have been better served to spend a little extra money on a higher performance storage system with 8 TBs of faster disk than on a low end NAS. With the higher performance 8TB array they would have benefited from better backup performance, faster restores, and improved performance of Backup & Replications advanced capabilities such as Instant Restore and SureBackup.