To collect backup files that belong to inactive backup chains from the extents and move them to object storage, 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 object storage repositories, 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 Legitimacy.
- Verifies whether source extents are available and have not been put into maintenance mode.
Consider that data will not be offloaded from Linux-based extents that have internet access via HTTP(S) proxy. All Linux-based extents configured in your scale-out backup repository must have direct access to the internet.
- Verifies whether an object storage repository 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 object storage 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 local and object storage repository 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 extents added to a scale-out backup repository.
- Extracts data blocks from these files and moves these blocks to object storage leaving the backup files only with metadata (i.e. free of data blocks).
Such backup files (without data blocks) will remain on the source extents and will also be replicated to the object storage repository.
Having a copy of such dummy files on your extents allows you to:
- Download data that was moved back to the extents, as described in Data Download.
- Restore data back to production servers, as described in Data Restore.
Having replicated versions of dummy files in object storage repositories allows you to:
- Synchronize the backup chain state of your object storage with that of your extents, as described in Synchronizing Capacity Tier Data.
The following figure illustrates how inactive backup chains are moved to object storage.
The Figure A demonstrates a pool of extents (A, B and C) that are added to a scale-out backup repository (SOBR) and an object storage repository that is added to the same SOBR.
Suppose that the 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 object storage repository 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 object storage repository.
Backup files with metadata (or dummy files) will be replicated to the object storage repository 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 object storage.
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.