This post is admittedly long overdue. The Scale-Out Backup Repository (SOBR) is a very powerful management technology that has been in Veeam Backup & Replication since v9, but I recently had a situation in our lab that made me remember how powerful this technology is, and I thought it appropriate to re-introduce this feature.
The situation was that I needed to remove a backup repository and I didn’t want to lose any backup data or restore points. It’s easy to do this with the SOBR, but there is so much more to it. Let’s re-introduce the SOBR!
What is the SOBR?
The SOBR is a logical collection of individual backup repositories (where backups go from a storage perspective) in one pool. The underlying repositories are referred to as extents and the parent SOBR is a collection of all the extents and will summarize their capacity. A picture helps describe this, so let’s look at the figure below:
This SOBR is a collection of six extents of different types holding backups from Veeam Agents, VMware vSphere, Microsoft Hyper-V and Nutanix AHV.
Why have this technology?
There are many reasons why the SOBR can add benefits to how organizations manage data in their environment. A few of the use cases that are available right now (and note – there will be more capabilities coming later this year) include:
- The ability to easily migrate underlying backup repositories in and out of the SOBR
- Data locality selection to keep backup files together within a job
- Performance policy to keep types of backup files on appropriately performing storage resources
- Invoke maintenance mode and evacuate extents as underlying repository needs change
These are just a few ways that the SOBR can solve real challenges in the data center for the backup infrastructure. If you have not, please check out the SOBR pages in Veeam Help Center. There you can find nearly 20 sub-pages on how the SOBR can be administered and its capabilities.
What does the SOBR do?
Like a regular repository, the SOBR holds backup data. The real benefits come when there need to be changes to the backup infrastructure. This will save administrators a lot of work in the following situations:
- A backup repository needs to be offline for maintenance
- A backup repository needs to be removed (such as being end-of-life or lease is up)
- Data needs to be evacuated from a backup repository
- Performance design can be improved
The performance design is something that can really be intriguing for those who have a mix of different storage systems. Some SOBR implementations will put incremental backups on a NAS or low-end SAN device and full backups on a deduplication appliance. This is an attractive arrangement as the performance profile of each of these types of backups files is in alignment with the storage capabilities of those extents.
Taking a backup repository offline is a very easy step. In the figure below, I have a SOBR with three extents: two local storage resources and one NAS device. The one local storage resource is on the C:\ drive — which is not optimal for backup placement. I can simply right-click and put this extent into maintenance mode.
Once a repository is in maintenance mode, an important fact must be considered: backups can still run. In this example, there are two other extents that are ready to receive backup jobs. This is a very powerful characteristic as we realize changes need to be made to the backup infrastructure over time, but we don’t want to be in a situation where we’re missing restore points to do such. This is one of the key deliverables that the SOBR has brought to Veeam installations from the beginning.
The extent can then have the backups evacuated, which will place the data on the remaining extents.
Once those backups are evacuated, the extent that is in maintenance mode can be removed from the configuration of the SOBR (and the remaining extents left in place) with ease.
What about smaller environments, can the SOBR help here also?
Truth be told, this was one of the first use cases of the SOBR! As the story is told to me, one of the first ideas came for the scenario where an organization had one backup repository. How could they move backup job configuration and data to a new backup repository with ease? This challenge was made easy with the SOBR.
I refer to this as a “Single-Instance SOBR” or basically a SOBR with one extent. The thought is, let’s have the SOBR defined but backed by only one extent. In this way, when the time arrives that the backup storage needs to be replaced or can’t be scaled to the size needed, an additional extent is added and then the first repository is placed into maintenance mode, backups evacuated, then removed from the SOBR configuration. Just like that — a new backup storage resource is in place without missing a single backup job. The figure below logically shows a Single-Instance SOBR:
In this configuration, the sole repository that is defined in the SOBR could be replaced by adding another extent with ease through the following steps (the unchanged part of the infrastructure made gray for simplicity):
The Scale-Out Backup Repository and you
The beautiful thing here is that we can let the world of day-to-day backup infrastructure administration leverage software-defined capabilities for backup storage. The management of the backup storage through this mechanism makes it very simple to make changes to the underlying storage while having absolute portability of the critical backup data.
Additionally, later this year we will be releasing more capabilities for the SOBR that will further drive the benefits needed today: portability, data management and new locations.
Are you using the SOBR? If so, how do you have it configured? Share your comments below.
