2.7 Capacity Tier

Historically, Veeam Backup & Replication has always used block storage devices as its main storage solution. This choice brought some huge benefits, like leveraging high performance of these systems and allow plenty of random I/O to guarantee fast backups and restores. However, service providers (and end users) have asked for cheaper options for those backups that don’t require a high RTO (Recovery Time Objective), especially Object Storage solution.

Stating in Veeam Backup & Replication 9.5 Update 4, the support for Object Storage systems has been added, and service providers can now leverage S3-compatible solutions on on-premises, or different solutions from public providers.

This new tier of storage is called “Capacity Tier” and it can be coupled with a Scale-Out Backup Repository, which then become the Performance Tier of the tiered solution. In fact, Veeam doesn’t use the new Capacity Tier as a direct target for backup and backup copy jobs, rather a new mechanism has been introduced. Let’s see how it works and how then service providers can design their storage with this new capability.

Architecture

The two tiers, Performance and Capacity, work in conjunction inside the same SOBR group. Once at least one object of each type is available in the environment, the service provider can add the Capacity Tier to the SOBR group.

2.23: SOBR design with Capacity Tier

The Capacity Tier is not consumed directly by Cloud Connect tenants, but it’s attached to a SOBR group as an additional Tier, while the multiple extents form the Performance Tier.

Note: Capacity Tier can only be attached to a SOBR group, not to a simple repository.

What’s different, compared to other storage types that are available in Veeam Backup & Replication, like Tapes, is that there’s no need for a dedicated job to move data between the two tiers: this operation is managed automatically by a policy that is applied to the SOBR group during the addition of the Capacity Tier:

2.24: Capacity Tier policy

The file movement is executed by each “Object Storage gateway”, following the configuration applied to the Object storage during its registration:

2.25: Define Capacity Tier gateways

This option is useful when consuming a public object storage, since potentially not every extent of the SOBR group is configured to connect to the public internet, or again an administrator would prefer to define a dedicated machine to act as the gateway between the SOBR group and the Internet.

In the case of on-premises Object storage however, we suggest to leave this option unselected, so that every extent in the SOBR group can interact with the Capacity Tier, guaranteeing at the same time better scalability and reliability.

Consumption

There are two policies available for the usage of Capacity Tier. The can also be used together.

Copy: The policy will automatically copy every backup file that is stored in the Performance Tier. In this way, each file will exist in both tiers, allowing for double protection of the backup files. This policy is very convenient for providers looking to increase the protection of their backups in an easy and automated way.

Move: The policy will automatically move every sealed backup file that is older than the defined period of days. If also the Copy policy is active, the net result will be that files will be then copies to the capacity tier, and later removed from the performance tier, so that the only copy left will be the one stored in the capacity tier.

It’s important to understand what files are moved (or deleted when both policies are active): by sealed Veeam means every file that doesn’t belong to a chain that is active at the time of the check (which happens every 4 hours). Let’s analyse the different use cases, but supposing a 7 days policy:

• Incremental with weekly Fulls (either synthetic or active): files of a previous chain will be moved to the capacity tier once a new full is created, since the new full itself “seals” the previous weekly chain. This can be compared to the deletion policy of old chains;
• Forever Forward Incremental: since there’s only one full for the entire duration of the chain, and every incremental depends on the full to be consistent, no files are moved. The only way to move files is to manually create a full backup;
• Reversed Incremental: only the Full file and the newest two incrementals needs to be stored locally, every other older .VRB incremental file can be moved to the archive;
• Backup Copy with regular retention: it acts like the Forever Forward Incremental in regards to capacity tier;
• Backup Copy with GFS: every file created here is a full file, so once it reached the age required by the capacity tier policy, it is immediately moved.

These information are important to explain to tenants the best way to configure their backups so to obtain for example cheaper offering for storage if the provider can use a Capacity Tier.

NOTE: the creation of periodic full in the chain is also needed for Insider Protection, so it definitively makes sense to suggest customers to use one of the optimal backup chain types.