Moving Backups to Capacity Tier
To collect backup files that belong to inactive backup chains from the performance extents and move them to the capacity tier, Veeam Backup & Replication uses an offload session which is executed automatically every 4 hours.
A complete name of each offload session is built up of the scale-out backup repository name + the Offload postfix. That is, if your scale-out backup repository name is Amazon, the offload session name will be Amazon Offload.
The offload session manages the following:
Before your data can safely be moved to the capacity tier, Veeam Backup & Replication performs the following mandatory verifications and required actions:
- Verifies whether data that is about to be moved belongs to an inactive backup chain.
For more information, see Backup Chain Detection.
- Verifies whether performance extents are available and have not been put into maintenance mode.
Consider that data will not be offloaded from Linux-based performance extents that have internet access through HTTP(S) proxy. All Linux-based performance extents configured in your scale-out backup repository must have direct access to the internet.
- Verifies whether the capacity extent has not been put into maintenance or seal mode.
- Verifies whether configuration parameters that define how and when inactive backup chains must be moved to the capacity extent are met.
Such parameters are configured as described in Add Capacity Tier.
- Builds and maintains indexes to verify whether data that is being moved is unique and has not been offloaded earlier.
For more information, see Indexes.
- Synchronizes the backup chain state between the performance and capacity extents to maintain retention policies.
For more information, see Retention Policy.
After the validation process is complete, the SOBR Offload session does the following:
- Collects backup files that have passed verification.
Such verified backup files are collected from all the performance extents added to a scale-out backup repository.
- Extracts data blocks from these files and moves these blocks to the capacity extent leaving the backup files only with metadata (i.e. free of data blocks).
Such backup files (without data blocks) will remain on the performance extents and will also be replicated to the capacity extent.
Having a copy of such dummy files on your performance extents allows you to:
- Download back to the performance extents the data that has been moved to the capacity extent, as described in Downloading Data from Capacity Tier.
- Restore data back to production servers, to Azure or Amazon EC2 cloud platforms or to your virtual machine, as described in Restore from Capacity Tier.
In this example, there is a scale-out backup repository and an object storage repository in the same scale-out backup repository.
The performance extent A has an inactive backup chain consisting of one .vbk file and three .vib files, that is, four restore points in total. Each of these files comprises metadata and the actual blocks of data. During the offload session, Veeam Backup & Replication will collect the actual blocks of data from all the backup files (.vbk and .vib) and offload these blocks to the object storage repository.
Each offloaded block might be of different size, which is defined during configuring storage optimization. The offloaded blocks are placed to the blocks directory in your capacity extent.
Backup files with metadata (or dummy files) will be replicated to the capacity extent and will be placed to the storages directory.
Such approach will be applied to all inactive backup chains that satisfy validation criteria.
After offload is complete, the new Object Storage node appears in the Home view, under the Backups node and shows backups that have been moved to the capacity extent.
The offload is not performed during prohibited hours specified in the scale-out backup repository backup window configuration. You can configure the backup window at the Add Capacity Tier step of the New Scale-out Backup Repository wizard.
Offload Session Statistics
The offload session results are saved to the configuration database and available for viewing, as described in Viewing Offload Job Session Results.