iland Cloud Backup leverages Veeam Cloud Connect for a simple and affordable way to back up your data to iland’s cloud environment.
When backing up your virtual machines to a remote repository, it is important to understand how Veeam holds backup files and the amount of storage that is consumed by these files. This helps calculate the storage quota needed for backups offsite so you can optimize your storage and minimize costs.
- I have created a test job that runs Forward Incremental backups with Synthetic Full backups on Thursdays. The job is set with a 7-day retention policy and I begin the process on a Monday.
- After my first backup job is complete on Monday, the repository folder is created with a VBK (Veeam Full Backup File) and the backup chain metadata file. The metadata file constructs the backup chain for Veeam.
- After Tuesday’s run we see our VBK file along with a Veeam Incremental Backup file or VIB. The VIB file is dependent on the VBK from Monday for a restoration of a VM. If I were to restore my test VM to the Tuesday recovery point, Veeam load restores the VBK file from Monday and rolls in the changes from the Tuesday VIB file.
- The job runs on Wednesday creating a new backup file. The VIB file from Wednesday is dependent on the VBK from Monday as well as the VIB from Tuesday. So if the Tuesday VIB was manually deleted, the backup chain would be broken. This would cause the backup job to fail and Veeam would not be able to restore a VM to Tuesday or Wednesday.
- Thursday’s run will be a little different from the others. Veeam creates a normal Veeam incremental backup job and file. However, you will see an extra task run as the files are being transformed by Veeam. When the process is complete, you will notice that the VIB file from Thursday has merged any changed block data from the previous backup files. This creates a new VBK file without having to run a Full Backup job through Veeam, which can take a significant amount of time. However, also note that the Synthetic full backup is the same size as a normal full VBK file, which is much larger than an incremental. So when deciding how much space is needed for your backups, keep in mind that you can have two VBK files at a given point in time when using Synthetic Full Backups.
- Friday, Saturday and Sunday run as expected, each creating a VIB file. These files are dependent on the Thursday Synthetic VBK file, which means a restore will complete quicker because Veeam does not have to restore the Monday VBK file and then roll up to one of these days. Thus the Synthetic Backup allows Veeam to create a full VBK without having to run a Full Backup job, taking load off production servers as all the work is done in the repository.
- My job is not configured to create Active Full Backups, only the Thursday Synthetic Full Backups. So when the second Monday comes around, an incremental is taken. This is where the Synthetic Full Backup chain becomes confusing. My second Monday run creates an incremental file since Full Backups are created synthetically on Thursday. However, the original Monday’s VBK file still exists. Right now, there is much more storage being consumed by backup files than expected. That is because there are currently two chains being used, the first Monday VBK with the Tuesday and Wednesday VIBs (Red Square) and The Thursday Synthetic VBK with VIBs after that (Blue Square). In order for Veeam to retain the 7-day retention, it must be able to restore back to Tuesday and Wednesday, which both depend on the VBK from Monday (Feb. 2nd).
- The 2nd Tuesday run creates a new VIB file. Again, this file is dependent on the Thursday VBK file and not the Monday VBK. However, Veeam is still unable to remove the original chain as it must be able to restore back to Wednesday February 4th to meet the 7-day retention policy.
- When the 2nd Wednesday run completes, a new Wednesday VIB file is created. This VIB is dependent on the Synthetic VBK and allows for Veeam to meet 7 days’ worth of retention. Therefore, Veeam is now finally able to remove the original Monday VBK and the backup chain with it, freeing up a significant amount of storage.
- From this point Veeam has a fresh new chain holding retention for the last 7 days, from 2/11 to 2/5. Another caveat to this is that the 12th will be another Synthetic backup, creating a new VBK file. As the chain that starts on the 12th progresses, Veeam keeps the chain starting on the 5th until the new chain is able to fulfill the 7-day retention policy. The screenshot below is from 2/17. The blue box is the current chain beginning 2/12. For the 7-day retention policy, Veeam must be able to restore back to the 2/11 (Yellow Box), which is in the 2/5 backup chain (Red Box). For this reason, Veeam keeps both backup chains until 2/18.
Eliminating Previous Backup Chain
- To prevent the above issue of retaining a past backup chain in your cloud repository, you can set Veeam to convert the previous backup chain into a roll back of VIB files.
- This option allows Veeam to remove the previous full backup file after creating a new Synthetic Full backup. Once that is complete, the incremental VIB files are then converted to Reverse Incremental files. This allows for the VIB files to depend on the newly created Synthetic File.
- The screenshot below shows the backup chain on Wednesday 2/11, with a Full Backup file from 2/5.
- On Thursday 2/12, a new Synthetic Full Backup is created. However, instead of creating a new chain and holding the old one, Veeam removes the VBK file from 2/5. Next, the incremental VIB files are converted to Reverse Incremental files allowing them to be restored using the 2/12 VBK file. You can see that the files names show the date of the restore point. So this chain maintains the 7-day retention policy allowing restores from 2/12 to 2/6.
- This method allows you to require only 1 VBK file and 6 VIB files rather than 2 VBK files and 11 VIB files.
Why not try it for free for 30 days for backup of up to 5TB data?