Veeam v13: Scale Out Backup Repository Design -- Performance Tier, Capacity Tier, and Extent Management

Veeam v13 Series | Component: VBR v13 | Audience: Enterprise Architects, Hands-on Sysadmins

The Scale Out Backup Repository is the most referenced feature in this entire series and the one that's never had its own article. If you've read the capacity planning piece, the Ootbi setup guide, the SOSAPI deep dive, or the tape and GFS article, you've seen SOBR mentioned as a given. This is the article that explains how to actually design and build one, what each tier does and when to use it, which decisions are hard to reverse, and how to manage extents as the environment grows.

There's also a real complexity trap with SOBR that catches people who deploy it quickly without reading the limitations first. The Data Locality vs Performance placement policy choice affects your entire backup chain integrity model. The Move vs Copy capacity tier mode has implications for chain types that most people discover the hard way. The per-VM backup file setting changes how extents are loaded and how data is distributed. This article covers all of it.

1. What SOBR Is and What It Isn't

A Scale Out Backup Repository is a logical grouping of storage that presents a single backup target to VBR jobs while managing data distribution, tiering, and growth across multiple underlying repositories. You point a backup job at the SOBR. VBR decides which physical extent gets the data. You add extents when capacity runs low. The SOBR namespace and job configuration don't change when you add storage.

What SOBR isn't: it's not a RAID array, it's not a distributed filesystem, and it's not a deduplication appliance. It doesn't provide redundancy within the performance tier. If one performance extent goes offline, the backup chains that have files on that extent are broken until the extent comes back. Plan for that.

SOBR requires Enterprise or Enterprise Plus licensing (or a Veeam Universal License). The standard edition is limited to two scale out repositories with three active extents and one sealed extent each. For production environments with multiple jobs and growth requirements, you need the Enterprise tier.

2. Performance Tier: Design and Extent Sizing

The performance tier is where active backup chains live. It consists of one or more standard backup repositories (Windows or Linux servers with local or SAN storage) or object storage repositories as extents. Each extent is an independently configured backup repository that you've already added to VBR's infrastructure before adding it to the SOBR.

Data Locality vs Performance Placement Policy

This is the most consequential design decision in SOBR configuration. You pick one policy at creation time. Changing it later requires rebuilding backup chains.

• Data Locality: All files in a backup chain (the full and all dependent incrementals) land on the same extent. The chain is never split across extents. If that extent goes offline, the chain is broken. But if it comes back online, the chain is intact. This is the right policy for most environments. It's simpler, safer, and works correctly with the capacity tier Move operation.
• Performance: Full backup files go to one extent, incremental backup files go to another. This spreads the I/O load during synthetic full creation, which matters if you're using raw NVMe devices and the transformation I/O is your bottleneck. The trade off is significant: if either extent goes offline during a job, the chain is broken and a full backup is triggered. Use this policy only on environments with high-performance homogeneous extents and reliable storage. It also requires a fast, reliable network connection between extents.

Extent Sizing

Size each extent using the same formula from the capacity planning article: (Full + Incrementals * Retention) * 1.25 / Data Reduction Ratio. The SOBR fills extents according to the placement policy and available free space per extent. An important operational note: the SOBR console view shows aggregate free space across all extents, but VBR's job scheduler checks free space per-extent before assigning a job. If one extent is full while others have space, jobs assigned to the full extent will fail even though the SOBR summary shows available capacity. This is why monitoring individual extent utilization matters, not just the SOBR total.

Immutability Consistency Requirement

If you enable immutability on any performance extent, you must enable it on all active performance extents. A mixed configuration where some extents are immutable and some aren't isn't supported. Plan your immutability strategy before adding extents, because retrofitting it to a SOBR with existing data requires sealed mode transitions on each extent.

3. Capacity Tier: Object Storage Configuration and Offload

The capacity tier extends the SOBR with object storage for data that doesn't need to live on fast local disk. You can attach one object storage repository as the capacity extent. It can be any supported object storage: AWS S3, Azure Blob, Wasabi, Backblaze B2, on-premises S3-compatible, or an S3 Integrated (SOSAPI) platform like Ootbi.

Move vs Copy Mode

Move mode transfers backup chain files from the performance tier to the capacity tier after they age out of the operational restore window you define. After transfer is confirmed, the data is removed from the performance extent. The performance tier reclaims the space. This is what most environments want.

Copy mode writes new backups to the capacity tier immediately as they're created, while keeping the copy on the performance tier. You end up with data on both tiers simultaneously. This doubles your storage consumption but gives you redundancy: if the performance tier fails, the data is on object storage. Use Copy mode when the performance tier doesn't have enough retention capacity and you want the capacity tier as a safety net, not as a tiering destination.

Critical constraint: Move mode requires the Data Locality placement policy. Forever forward incremental jobs can't use Move mode at all. Only forward incremental jobs with synthetic fulls support Move. This is documented in the official Veeam best practices guide and is the reason to choose your chain type and placement policy before configuring the capacity tier.

Offload Window and Task Sizing

The SOBR offload job runs daily and uses repository task slots to transfer data to object storage. Repository task slots are shared across all jobs: backup jobs, restore jobs, copy jobs, and the SOBR offload all compete for the same slots. Restore jobs get highest priority. The SOBR offload gets lowest priority. If your backup window overlaps with the offload window, backups will starve the offload job.

Size offload task slots at one CPU core per task, 2 GB RAM per task, on the gateway server that handles object storage writes (typically the VBR server itself unless you've configured a dedicated gateway). The Veeam blog recommends keeping concurrent S3 connections below 2048 for on-premises object storage (32 task slots * 64 connections per task) and below 6016 for public cloud providers.

S3 Integrated vs S3 Compatible

If your on-premises object storage supports SOSAPI (the blue S3 Integrated icon in VBR), the capacity tier gets live capacity visibility, capacity aware SOBR extent selection, and Smart Entity routing for multi-node platforms. VBR polls capacity.xml in the hidden .system folder every 4 minutes and uses that data to make better placement decisions. Without SOSAPI (green S3 Compatible icon), VBR operates blind on capacity. The capacity column shows "Unlimited" and VBR can't route data to the optimal node on a multi-node cluster. For on-premises object storage that will receive significant offload traffic, SOSAPI support is worth prioritizing in your platform selection. The SOSAPI deep dive article in this series covers the mechanics in detail.

4. Archive Tier: Tape Integration

The archive tier adds a third level of storage below the capacity tier, backed by tape. Data moves from the capacity tier to tape according to an age threshold you configure. Archive tier tape targets are configured as standard tape media pools in VBR. The archive tier doesn't write directly from the performance tier, it reads from the capacity tier.

One important restore behavior: restoring from the archive tier requires a preparation step. VBR has to stage the data from tape back to the capacity tier before the restore can begin. This is the same staging process described in the tape article, and it adds meaningful time to any restore from this tier. The archive tier is for data you're keeping for compliance and legal hold, not for data you expect to restore operationally. The operational restore window should live entirely in the performance and capacity tiers.

5. Per-VM Backup Files and SOBR Implications

The per-VM backup files setting (also called per-machine backup files) controls whether VBR stores each VM's backup chain as a separate set of files or combines multiple VMs into a single backup file per job. For SOBRs, this setting has significant implications for how data is distributed across extents and how the capacity tier offload works.

• Per-VM backup files enabled: Each VM gets its own VBK/VIB files. Each VM's chain can land on a different extent based on the placement policy. The capacity tier offload can move individual VM chains as they age out independently. This is the right setting for SOBRs with large job sets and multiple extents, because it enables granular placement and offload.
• Per-VM backup files disabled: All VMs in a job share a single set of backup files. The entire job's data lands on one extent together. The capacity tier can only offload the entire job chain at once, not individual VMs. This produces larger files that are harder to distribute and harder to offload granularly.

Object storage performance extents always use per-VM backup files regardless of the job setting. This is enforced by VBR. If you're using object storage as a performance extent, you'll see separate backup chains per VM whether you've enabled the setting or not. This is documented in the official SOBR limitations page.

AHV backups always use per-VM backup files too, also regardless of the job setting. It's a Veeam Plug-in for Nutanix AHV implementation detail, not a configuration choice.

6. Managing Extents: Adding, Evacuating, and Replacing

Adding an Extent

Adding an extent to an existing SOBR is non-disruptive. Running jobs aren't affected. VBR immediately starts considering the new extent for new backup chain placement based on the placement policy and available free space. Existing backup chains don't move automatically: they stay on their current extents unless you explicitly evacuate or use storage vMotion on individual chains.

Evacuating an Extent

Before removing or replacing an extent, you must evacuate it. Evacuation moves all backup chains from the extent to other available extents in the SOBR. The process runs in the background and doesn't require downtime, but it does consume repository task slots and network bandwidth. On a large extent with many backup chains, evacuation can take hours. Plan for this when scheduling maintenance.

1. Put the extent into Maintenance mode: right click the extent in the SOBR properties and select Maintenance Mode. This stops new data from being written to the extent while allowing reads.
2. Right click the extent and select Evacuate. VBR moves all backup chains to other extents. Monitor progress in the SOBR properties view.
3. After evacuation is confirmed complete, remove the extent from the SOBR.

Sealed Mode

Sealed mode is different from Maintenance mode. A sealed extent stops accepting new backup chains but continues to serve existing chains for reads and incremental writes until those chains are offloaded or expired. VBR won't write new chains to a sealed extent, but it will continue writing incrementals to existing chains that are already there. Sealed mode is used when you want to drain an extent gradually over time without forcing an immediate evacuation, or when you need to add a different type of object storage to a tier that already has one vendor's storage (mixed vendor S3 compatible requires one to be sealed).

7. Backup Copy Jobs and SOBR as Target

Backup copy jobs can target a SOBR the same way primary backup jobs do. The copy job writes to the performance tier extents according to the same placement policy. The capacity tier offload and archive tier then apply to copy job data the same way they apply to primary backup data.

The important consideration with backup copy jobs and SOBR is the GFS retention interaction. If you're using GFS retention on the backup copy job and the SOBR has a capacity tier with Move mode, the full backups designated as GFS points need to stay accessible on the performance tier for longer than regular backups. VBR respects the GFS retention flags and won't move a GFS full backup to the capacity tier before its GFS retention period expires. This means GFS-flagged fulls can accumulate on the performance tier and consume more space than you'd expect. Account for GFS retention duration when sizing performance tier capacity for SOBRs that receive copy job traffic.

8. PowerShell Automation for SOBR Management

# NOTE: Add-VBRScaleOutBackupRepository and Set-VBRScaleOutBackupRepository
# accept many parameters. The confirmed-safe subset for initial creation is shown here.
# For the full parameter list including capacity tier configuration options,
# see: https://helpcenter.veeam.com/docs/vbr/powershell/add-vbrscaleoutbackuprepository.html

Connect-VBRServer -Server "vbr-server.domain.local"

# Step 1: Get the existing repositories that will become extents
$ext1 = Get-VBRBackupRepository -Name "Repo-Node1"
$ext2 = Get-VBRBackupRepository -Name "Repo-Node2"
$ext3 = Get-VBRBackupRepository -Name "Repo-Node3"

# Step 2: Create the SOBR performance tier
# Use the VBR console wizard to configure the capacity tier and archive tier:
# Backup Infrastructure > Scale-out Repositories > right-click SOBR > Edit
$sobr = Add-VBRScaleOutBackupRepository `
    -Name "SOBR-Production" `
    -Extent @($ext1, $ext2, $ext3)

Write-Host "SOBR created: $($sobr.Name)"
Write-Host "Extents: $($sobr.Extent.Count)"

# Step 3: Verify the SOBR is accessible and shows all extents
Get-VBRBackupRepository -ScaleOut -Name "SOBR-Production" | Select-Object Name, PolicyType

Disconnect-VBRServer

Connect-VBRServer -Server "vbr-server.domain.local"

Get-VBRBackupRepository -ScaleOut | ForEach-Object {
    $sobr = $_
    Write-Host "`nSOBR: $($sobr.Name)"
    Write-Host "  Policy: $($sobr.PolicyType)"
    Write-Host "  Extents:"

    $sobr.Extent | ForEach-Object {
        $repo     = $_.Repository
        $totalGB  = [math]::Round($repo.Info.CachedTotalSpaceMb / 1024, 1)
        $freeGB   = [math]::Round($repo.Info.CachedFreeSpaceMb  / 1024, 1)
        $usedGB   = $totalGB - $freeGB
        $pct      = if ($totalGB -gt 0) { [math]::Round(($usedGB / $totalGB) * 100, 0) } else { 0 }
        $state    = $_.IsSealed ? "SEALED" : ($_.IsInMaintenance ? "MAINTENANCE" : "Active")
        $warn     = if ($pct -ge 80) { " *** WARNING" } else { "" }

        Write-Host "    [$state] $($repo.Name): $usedGB GB / $totalGB GB ($pct%)$warn"
    }
}

Disconnect-VBRServer

Connect-VBRServer -Server "vbr-server.domain.local"

# Add a new extent to an existing SOBR
$sobr    = Get-VBRBackupRepository -ScaleOut -Name "SOBR-Production"
$newRepo = Get-VBRBackupRepository -Name "Repo-Node4"

Set-VBRScaleOutBackupRepository -Repository $sobr -AddExtent $newRepo
Write-Host "Added $($newRepo.Name) to $($sobr.Name)"

# Report how backup chains are distributed across extents
$extentMap = @{}
$sobr.Extent | ForEach-Object { $extentMap[$_.Repository.Id] = $_.Repository.Name }

Get-VBRBackup | Where-Object {
    $_.RepositoryId -eq $sobr.Id
} | Group-Object { $extentMap[$_.TargetRepositoryId] } | ForEach-Object {
    Write-Host "$($_.Name): $($_.Count) backup job(s)"
}

Disconnect-VBRServer

Connect-VBRServer -Server "vbr-server.domain.local"

$sobr       = Get-VBRBackupRepository -ScaleOut -Name "SOBR-Production"
$extentName = "Repo-Node1"

# Find the extent's repository object within the SOBR
$extentRepo = ($sobr.Extent | Where-Object { $_.Repository.Name -eq $extentName }).Repository

if ($null -eq $extentRepo) {
    Write-Error "Extent '$extentName' not found in SOBR '$($sobr.Name)'"
    exit 1
}

# Enable Maintenance mode on the extent
# This stops new backup chains from being written to this extent
# Evacuation (moving existing chains to other extents) runs automatically
# after Maintenance mode is enabled and all active jobs targeting this extent complete
Write-Host "Enabling Maintenance mode on $extentName..."
Enable-VBRRepositoryExtentMaintenanceMode -Repository $sobr -Extent $extentRepo

Write-Host "Maintenance mode enabled. VBR will evacuate existing chains to other extents."
Write-Host "Monitor progress in VBR console: Backup Infrastructure > Scale-out Repositories"
Write-Host "Remove the extent only after evacuation shows 100% complete."

# To disable Maintenance mode later (if you change your mind):
# Disable-VBRRepositoryExtentMaintenanceMode -Repository $sobr -Extent $extentRepo

Disconnect-VBRServer