Skip to main content

Intro

An often overlooked feature we can leverage since V11 is the archive tier for the Scale-Out-Backup-Repository (SOBR).

SOBR: Tiers against fears… 😉

While we find quite some good guidelines for the Veeam side of the functionality (e.g. Archiving Backup with Microsoft Azure Blob | Veeam Community Resource Hub), I’d consider it helpful to have some more insights to the technology and a guideline to also set up the hyperscalers side of the archive tier. I’ll choose Microsoft Azure here as an example. In the following blogpost with four parts (TLDR), I’ll walk you through some background and the complete setup. 

 

A short history of the SOBR

A scalable storage layer for backups is crucial for larger environments. This is why Veeam brought us the Scale-Out-Backup-Repository with VBR version 9.0 already. First it only consisted of the so called “performance tier” – that is the on-premises storage devices being pooled together as so called “extents” in a very flexible way.

With Version 9.5 U4 the integration of another tier was achieved, allowing to connect S3 compatible object storage to the SOBR. This tier was called “capacity tier” as it allowed to add more storage by means of a capacity extension. In 9.5 U4 it was more or less only an “archiving” tier, as it supported only the move mode. This relocates older backups from the performance tier on disk to the S3 bucket after a defined period of time thus freeing the space on disk for newer backups.

With V10 we already saw the “copy mode”. This now allowed us to fully leverage the capacity tier of the SOBR to obey the 3-2-1 rule by having a copy of the backups in another site.

It could even be considered an air-gapped backup as it is only accessible via an API and no direct access to disks whatsoever is possible. Direct deletion from within Veeam by a rogue admin though is still possible.

But with certain hyperscalers (e.g.: AWS) and several on-prem S3 storage systems even true immutability is possible by hard-protecting the objects from deletion for a definable but then fixed time period. This is the way to go for full ransomware resilience.

With version 11 of VBR we now are able to integrate a third type of storage into the SOBR – now being called “archive tier”. In the following blogpost series, we will have a deeper look at what justifies another tier and the advantages and disadvantages it brings us. 

Read on in part two of this blogpost: SOBR Archive Tier – Explained and Configured – Part 2 of 4 | Veeam Community Resource Hub

Great start to a series. 👍


Comment