With Veeam 9.5 update 4 you are now able to add Backup Repositories that are comprised of iland Object Storage. This Object Storage Repository cannot be used as the target of a backup or copy job as it is intended to expand the capacity of your existing local storage. This is done by adding the Object Storage Repository as a Capacity Tier extent to an existing Scale Out Backup Repository (SOBR). Once added in, you can configure you SOBR to offload data from your backup chain to the Object Storage Repository, allowing you to reduce storage usage locally and increasing your retention capabilities. Let's take a deeper look the Capacity Tier within SOBR.
You can visit the following pages for technical instructions on Creating a SOBR in Veeam or Creating a Veeam Backup Repository on Object Storage.
When creating a Scale Out Backup Repository in Veeam 9.5 Update 4, you now designate repositories for your Performance and Capacity Tiers. The Performance Tier would include any local backup repositories that have been added to your Veeam Backup Infrastructure. The Capacity Tier can then be configured next by adding in an object storage based repository. This Capacity Tier extends the storage of your existing local backup repositories by offloading data from your local backup files to your object storage repository.
When configuring the Capacity Tier of your SOBR, you will need to configure an Operational Restore Window. This window would be the length, in days, that you wish to keep a backup file fully complete on your local Performance Capacity. Backup files that are aged within the operational window remain untouched locally on your Performance Tier storage. However, once a backup file ages out of this Operation Restore Window, it can potentially be dehydrated and offloaded to the Capacity tier. I say potentially because a backup file has to also be apart of the inactive section of your backup chain to be offloaded. More on that later.
First, lets take a look at an example of how a SOBR with a Capacity Tier works. In the screenshot below, you can see the restore points created for my Local Backup Job. These backups are saved on a SOBR that is offloading data to my Capacity Tier after 1 day. The red box includes all of my backup files that have been dehydrated and offloaded to the capacity tier so far.
You can see my first full backup (.vbk) file was created 1/31/2019 and after compression and deduplication I have a backup file size of 9.44GB. You can also see that the files moved to the capacity tier have a cloud icon to the left of the backup file name. When looking at the backup files using the file explorer in the Veeam console, you can see the affect of the Capacity Tier offloading.
In the screenshot above, you can again see the backup files that have been offloaded to the Capacity Tier within the red box. However, you will now notice that the file size has compressed to 21MB for all files, including the full VBK file that was previously 9.44GB. The rest of the data for these backup files has been offloaded to the object storage repository in the Capacity Tier. It is important to remember that these backup files are not archived or fully moved to Object Storage. Once a backup file in the Performance Tier is removed by your job's retention policy, the respective data in the Capacity Tier is removed as well.
As mentioned above, this SOBR was configured to offload data after 1 day, meaning my Operational Restore Window is 1 day. If you look closely though, you should see multiple backup files in the chain that are older than a day old but have yet to be offloaded to the Capacity Tier. Veeam will automatically check for and offload backup data to the Capacity Tier every 4 hours, so there should have been several opportunities my files to be dehydrated.
The reason for this is because many of my backup files are a part of the Active Backup Chain for my job. Let's take a look back at the restore points for the Local Backup Job. The backups in the red box still contain the backup files that have been offloaded to the Capacity Tier, but this group of backup files also represents the Inactive Backup Chain of the job. This job is using the Forward Incremental backup method, as you can see because I have .vib files rather than .vrb(reverse incremental files).
The last restore point created within the red box was created at 6:00 PM 2/1/2019. The backup size is pretty small, not only because these are basic demo servers in lab, but also because it only contains changes from the previous backups. So, when recovering a server from this restore point, Veeam will need to compile data from each incremental backup before until it reaches the most recent full backup (.vbk) file. However, at midnight on 2/2/2019 a new full backup file was created which you can see at the bottom of the blue box. This new .vbk file begins a new Active Backup Chain and any new incremental file created will rely on this full backup file. So, all previously created backups are now considered the Inactive Backup Chain. For more information on the Backup Chain Legitimacy, please visit: https://helpcenter.veeam.com/docs/backup/vsphere/capacity_tier_inactive_backup_chain.html?ver=95u4.
Veeam will only offload data from backup files in the Inactive Backup Chain. Since these files will not be actively updated or changed during future backups, it is safe to move the majority of data to Object Storage free up space on your Performance Tier. Restoring data or full VMs from the Capacity Tier works in the same manner as well without any extra steps.