Capacity Tier Offload to Object Storage

The Capacity Tier is the object storage tier attached to a Scale-Out Backup Repository. It solves two problems: on-premises storage capacity limits, and the need for off-site backup copies without running a full second backup job or maintaining a second set of backup infrastructure at a remote location.

Data in the Capacity Tier is stored in a proprietary Veeam format - not the same as the VBK/VIB files on performance extents. Veeam extracts the actual data blocks from backup files and writes them individually to object storage, along with metadata that describes how the blocks fit together. This block-level storage format means the data in the Capacity Tier cannot be read by anything other than Veeam, but it also means Veeam can use deduplication and optimize storage at the block level rather than at the file level.

Restores from the Capacity Tier work directly - you do not need to copy data back to the performance tier before restoring. Veeam downloads only the blocks required for the restore, not the entire backup file. For instant VM recovery and other restore operations that reference specific blocks, this is efficient. For full VM restores from older Capacity Tier restore points, performance depends on your internet egress bandwidth and the object storage provider's retrieval speed.

The Capacity Tier supports two data movement modes, and they serve different architectural purposes. You can enable both simultaneously, and in most production environments you should.

Copy mode (Copy backups to object storage as soon as they are created) sends a copy of each new restore point to the Capacity Tier the moment it is created on a performance extent. The performance extent retains its copy. Every restore point exists in two places from the moment it lands - on-premises and in object storage. This is the right mode when your primary concern is availability: if the performance extent fails or is compromised by ransomware, the Capacity Tier copy is intact and immediately usable.

Move mode (Move backups to object storage as they age out of the operational restores window) moves inactive backup chains - chains that have aged past the operational restore window - from performance extents to the Capacity Tier. After the move, data exists only in object storage. The performance extent space is reclaimed. This is the capacity management mode: keep recent backups fast and local, push old backups to cheaper object storage automatically.

Running both simultaneously gives you the full picture: Copy mode ensures every new restore point lands in object storage immediately, while Move mode ages out the on-premises copies of older restore points to reclaim local capacity. This is the configuration that provides both data protection and capacity management without requiring separate backup copy jobs.

Veeam runs Capacity Tier offload sessions automatically every 4 hours. The session is named after the SOBR with an Offload suffix appended - if your SOBR is named Primary-SOBR, the offload session appears as Primary-SOBR Offload in the session history.

Before moving any data, the offload session performs mandatory verifications. It checks that the backup chain is inactive - meaning all restore points in the chain are beyond the operational restore window. It synchronizes backup chain state between the performance extent and the Capacity Tier to ensure retention policies are accurate on both sides. Only backup chains that pass these checks are eligible for offload.

When the offload runs, it collects data blocks from the verified backup files across all performance extents and writes them to object storage. The blocks from VBK (full) and VIB (incremental) files within the same chain are all offloaded together. Once the offload of a chain is verified complete, the original files on the performance extent are removed and the space is reclaimed.

The offload window controls when sessions are permitted to run. By default, offload can run at any time. Configure the window to restrict offload to off-peak hours if you need to protect backup performance during active backup windows.

Before configuring the Capacity Tier, you need an object storage repository added to Veeam. This is covered in the repository configuration article in this series. The quick summary for Capacity Tier use cases:

For AWS S3: create a dedicated bucket with versioning enabled. If you want immutability, create the bucket with Object Lock enabled from the start - you cannot add Object Lock to an existing bucket. Use a dedicated IAM user with minimum required permissions scoped to the Veeam bucket only. Select the correct regional endpoint for your bucket location.

For Wasabi: create a bucket in the Wasabi region closest to your backup server. Object Lock is available in all Wasabi regions. Wasabi does not charge for egress when restoring to Veeam - this is a meaningful cost difference compared to AWS for restore-heavy workloads. Use Wasabi-specific endpoints, not AWS endpoints, when configuring the S3-compatible object storage repository.

For Azure Blob Storage: create a storage account and a container dedicated to Veeam backup data. Azure Blob immutability policies apply at the container or blob level. Configure the storage account with LRS, ZRS, or GRS replication based on your durability requirements. RA-GRS or RA-GZRS provides geo-redundant storage with read access to the secondary region.

For all providers: create a dedicated folder within the bucket or container for Veeam Capacity Tier data. Do not share the folder with other tools or processes. Do not change the folder name after data has been written - it is embedded in the SOBR configuration and changing it breaks the repository reference.

Capacity Tier configuration is part of the SOBR wizard. For a new SOBR, reach the Capacity Tier step in the wizard. For an existing SOBR, edit its properties and navigate to the Capacity Tier step.

Data offloaded to the Capacity Tier can be encrypted before it leaves your network. Enable this by checking Encrypt data uploaded to object storage in the Capacity Tier step and providing a password.

This encryption is applied at the SOBR Capacity Tier level, separate from any job-level encryption. If your backup jobs are already encrypting data, enabling Capacity Tier encryption adds a second layer. For data going to a public cloud provider, enabling at least one layer of encryption is the right call - either at the job level or the Capacity Tier level. If both are enabled, data is double-encrypted, which has a compute cost but provides defense in depth.

The Capacity Tier encryption password is managed separately from job encryption passwords. Store it in a secure location - losing this password means losing access to all data in the Capacity Tier, including any data that has been moved (not just copied) from performance extents. There is no Password Loss Protection fallback for Capacity Tier encryption the way there is for job encryption via Enterprise Manager.

Restores from the Capacity Tier work through the same restore workflow as standard repository restores. In the VBR console, select the VM or backup, choose the restore type, and select a restore point. Restore points in the Capacity Tier are displayed alongside restore points on performance extents - there is no separate restore path for Capacity Tier data.

When you initiate a restore from a Capacity Tier restore point, Veeam downloads the required data blocks from object storage. For instant VM recovery, Veeam mounts the VM directly from object storage using a streaming approach that reads blocks on demand rather than downloading everything first. For full VM restore, all required blocks must be downloaded before the restore completes.

Restore performance from the Capacity Tier depends entirely on your internet egress bandwidth and the object storage provider's transfer speed. For Wasabi, there is no egress cost, which matters when you are doing large restores. For AWS S3 Standard, egress is charged per GB and can add up quickly on large restores - factor this into your total cost of ownership calculation when choosing a provider for Capacity Tier use.

For disaster recovery scenarios where the performance extents are lost and the Veeam backup server itself is gone, see the next section on importing object storage backups.

Object storage immutability protects Capacity Tier data from deletion or modification during the immutability period. When immutability is configured on the object storage repository used as the Capacity Tier, Veeam sets object lock retention on data blocks as they are written. Even if the Veeam backup server is compromised and attempts to delete Capacity Tier data, the object storage provider enforces the retention and blocks the deletion.

Immutability in the Capacity Tier requires the underlying bucket to have Object Lock enabled (AWS S3, Wasabi) or the equivalent immutability feature enabled before Veeam writes any data. It cannot be added retroactively to a bucket that already contains Capacity Tier data.

Set the immutability period on the object storage repository to at least the length of your longest retention requirement. If Move mode is enabled and you keep 90 days of restore points, set immutability to at least 90 days. Shorter immutability periods mean that older restore points age out of immutability protection before they are deleted by retention, leaving a window where they could be deleted by a compromised system.

If the Veeam backup server and all performance extents are lost - a data center disaster, ransomware that destroyed the on-premises infrastructure - the Capacity Tier in object storage remains intact. Veeam provides a mechanism to import these backups directly from object storage into a new or replacement VBR installation without recreating the original SOBR configuration.

The import process works by adding the object storage repository to the new VBR installation and using the Import Backup function (also referred to as Importing Object Storage Backups in the documentation) to scan the bucket and reconstruct the backup inventory from the stored metadata. Once imported, the Capacity Tier backups are visible in the Home view and available for restores directly from object storage.

This workflow requires knowing the bucket credentials, folder path, and if encryption was enabled, the Capacity Tier encryption password. These are the three pieces of information that must survive a disaster scenario for the Capacity Tier to be usable for recovery. Store them in a location that is not on the same infrastructure being protected - a separate cloud secrets manager, a secure offsite document, or a physical security vault. The backup data surviving in object storage is meaningless if the credentials and encryption password are lost along with the backup server.

Existing Capacity Tier configurations from v12 carry forward to v13 without changes. The object storage repository references, encryption settings, offload windows, and data movement mode settings all survive the upgrade. Data already in the Capacity Tier from v12 remains accessible and readable in v13.

After upgrading to v13, review the Capacity Tier configuration for any SOBRs that use generic S3-compatible storage. If you have multiple S3-compatible repositories in the same SOBR tier (from different providers), the v13 rule requires one to be in sealed mode. Verify your configuration does not conflict with this requirement post-upgrade. AWS S3 and Wasabi are exempt from this restriction - it applies only to generic S3-compatible endpoints.

The Archive Tier is also available in v13 for environments that need a third storage level below the Capacity Tier for long-term retention. If you have compliance requirements that mandate multi-year backup retention at minimal cost, review the Archive Tier option. It can be added to an existing SOBR by editing the SOBR properties without disrupting existing Capacity Tier configuration or data.