This is an archive version of the document. To get the most up-to-date information, see the current version.SOBR Offload Job
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 job governs the following:
Before your data can safely be offloaded to object storage repositories, Veeam performs the following mandatory verifications and required actions:
- Verifies whether data that is about to be offloaded 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 mode.
For more information, see Switching to Maintenance Mode.
- Verifies whether policies that define how and when the backup data should be offloaded are met.
Policies are configured, as described in Add Capacity Tier.
- Builds and maintains indexes to verify whether data that is being transferred 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 job 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 offloads 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 these files on your extents allows you to:
- Download offloaded data back to the extents, as described in SOBR Download Job.
- Restore your data back to production servers, as described in Data Restore.
Having replicated versions of these 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 an abstract transfer process.
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 will collect all the orange squares — that is, 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 of your object storage repository.
Backup files with metadata will also 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 shown in the Figure B.
Such an approach will be applied to all inactive backup chains of all the extents added to SOBR.
Offload Session Statistics
The offload job session results are saved to the configuration database and available for viewing, as described in Viewing Offload Job Session Results.
Related Topics