2.8 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 different solutions now that Object Storage has become popular, either for having a cheaper alternative, for better redundancy (thanks to the inner scale-out capabilities) or other reasons.

Stating in Veeam Backup & Replication 9.5 Update 4, the support for Object Storage systems has been added and service providers can leverage S3-compatible solutions on on-premises, or different solutions from public providers. We described in previous chapters the use of Object Storage as a Backup Repository, but this technology can also be used as an additional layer, combined either with Block Storage or another Object Storage.

This new tier of storage is called Capacity Tier and it can be coupled with a primary storage inside a Scale-Out Backup Repository: the primary storage becomes the Performance Tier of the tiered solution. While Performance Tier is the direct target for backup and backup copy jobs, the capacity tier is used to offload the backups once they are received.

Architecture

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

2.21: SOBR design with Capacity Tier

NOTE: technically, a third tier is possible in a SOBR, the Archive Tier. However, due to its low usage among providers, we will ignore it in this document.

The Capacity Tier is not consumed directly by Cloud Connect tenants, but it’s attached to a SOBR as an additional Tier. Capacity Tier can only be attached to a SOBR, 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 during the addition of the Capacity Tier:

2.22: Capacity Tier policy

Connection to the Object Storage can happen in two ways, Direct or Through a gateway server:

2.23: Choose connection mode to the Object Storage

Gateway mode is useful when consuming a public object storage, since potentially not every extent of the SOBR is configured to connect to the public internet, or again an administrator would prefer to define a dedicated machine (not evn part of SOBR) to act as the gateway between the SOBR Performance Tier and the Capacity Tier located on the Internet.

In the case of on-premises Object storage, we suggest to define the SOBR extents as gateways, as showed in the screenshot. In this way multiple extents 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. They 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.