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 Detect.
- 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 via 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 Data Download.
- Restore data back to production servers, to Azure or Amazon EC2 cloud platforms or to your virtual machine, as described in Data Restore.
Having replicated versions of dummy files in the capacity extent allows you to synchronize the backup chain state of your capacity extent with that of your performance extents, as described in Synchronizing Capacity Tier Data.
The following figure illustrates how inactive backup chains are moved to the capacity extent.
The Figure A demonstrates a pool of performance extents (A, B and C) that are added to a scale-out backup repository (SOBR) and a capacity extent that is added to the same SOBR.
Suppose that 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 (represented as green vertical blocks) and the actual blocks of data (represented as yellow squares). During the offload session, Veeam Backup & Replication will collect all the orange squares — that is, the actual blocks of data — from all the backup files (.vbk and .vib) and offload these blocks to the capacity extent represented in the Figure B.
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. As per example, these files are one .vbk file and three .vib files that are shown in the Figure B.
Such an 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.
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.