Learn Veeam - Scale-Out Repositories & Capacity Tier

#Introduction

In episode 6 we introduced SOBR; now we go deep into it. When the number of VMs and data grows, a single repository is no longer enough — capacity runs out, performance drops, and costs spike. In episode 18 we build the Scale-Out Backup Repository (SOBR) with a capacity tier and an archive tier, plus scaling with multiple proxies.

The goal is simple: storage that grows without breaking — hot data on fast disks, cold data on cheap object storage, and everything looks like a single repository to jobs.

#SOBR: Combining Repositories

#Performance Tier: Extents

SOBR is a container holding one or more repositories (called extents) used as the performance tier — where new backups are written. Jobs just point to the SOBR; Veeam distributes data across extents (and picks the one with the most free space).

Create a SOBR with one extent

$repo = Get-VBRBackupRepository -Name "LinuxRepo1"
$sobr = Add-VBRScaleOutBackupRepository -Name "SOBR-Prod" `
    -Extent $repo -UsePerVmFiles

#SOBR Benefits

One namespace — jobs don't need to know which repo is used.
Scalable extents — add repositories when capacity runs low.
Per-VM backup files — each VM has its own file set (easier granular restore/offload).

#Capacity Tier: Offloading to Object Storage

#How Offload Works

The capacity tier is object storage (S3-compatible) connected to the SOBR. Veeam offloads old restore points from the performance tier to object storage based on policy (e.g. move backups older than 30 days). The performance tier stays clean and fast; old data lives on cheap storage with practically unlimited capacity.

SOBR offload flow

Job ──▶ SOBR performance tier (fast disk)
                │  offload (policy: age/quantity)
                ▼
        Capacity tier (S3 / object storage, cheap)

#Adding a Capacity Tier

Add S3 object storage to the SOBR, choose the offload policy, and define the backup copy in object storage. Veeam supports restoring directly from the capacity tier — data can still be recovered without migrating it back.

#For Cold Data: Archive Tier

For very cold storage, the archive tier moves restore points to Glacier (or S3 Glacier Deep Archive / similar cloud storage) — very low cost for rarely accessed data, with retrieval costs when needed. Configure it at SOBR → Archive tier: choose the data age that can be archived.

Tip

Proper tiering design separates speed from cost: the performance tier is optimized for daily backup/restore, the capacity tier for long retention, and the archive tier for long-term compliance (years). You only pay for fast disks where data really needs speed.

#Scale: Multiple Proxies and Thousands of VMs

#Load-Balanced Proxies

A single proxy has a throughput limit. For large environments, register multiple proxies — Veeam automatically distributes jobs/tasks to the available proxies. Each job splits VMs into tasks; each task is handled by one proxy.

Check proxy load

Get-VBRBackupProxy | Select-Object Name,Status,NumberOfTasks | Format-Table -AutoSize

Scale rules of thumb:

≤ 100 VMs — 1-2 proxies are enough.
100-500 VMs — 2-4 proxies, prioritize SAN/HotAdd transport.
Thousands of VMs — proxies per site/per storage, multi-extent SOBR, planned network throttling.

#Scaling SOBR for Thousands of VMs

For thousands of VMs, combine:

Many extents in the performance tier (multiple Linux servers).
A large capacity tier on object storage (automatic offload).
Multiple load-balanced proxies per segment.
Per-VM backup files for granular offload and restore.

Warning

Scale is a design result, not accumulation. Adding 10 proxies to an architecture whose bottleneck is the repository or network only adds cost. Before scaling out, measure the bottleneck: proxies (CPU/network), repository (I/O), or WAN. Episode 20 (Veeam ONE) helps you measure these with real data.

#Verification

After this episode, make sure:

A SOBR is formed with an active performance tier (extent).
The S3 capacity tier is connected and the offload policy is active.
(Optional) The archive tier to Glacier is configured.
Multiple proxies are registered and load-balanced.

#Closing

Key takeaways:

SOBR = one namespace from several repositories (performance tier).
The capacity tier offloads old data to S3 object storage (cheap, unlimited).
The archive tier moves very cold data to Glacier.
Scale: load-balanced multiple proxies + multi-extent SOBR for thousands of VMs.
Measure bottlenecks before adding resources — scale is design, not accumulation.

In the next episode, episode 19, we will cover cloud & hybrid backup — backing up to cloud object storage (AWS/Azure/GCP, S3-compatible), Veeam Cloud Connect (service providers), Azure VM backups, and realizing the 3-2-1 rule with cloud off-site copies and DR to cloud. Your infrastructure will go beyond the data center walls!