Veeam v13: Configuring Backup Repositories (Local, SOBR, Object Storage)
Repository Types and When to Use Each
Veeam supports several repository types, and understanding which one fits which use case saves you from architectural decisions that are painful to undo later. The three categories you will work with most often are standard backup repositories, hardened Linux repositories, and object storage repositories - plus the Scale-Out Backup Repository (SOBR) that combines them.
A standard backup repository is a Windows or Linux server with local or DAS storage, or an SMB/NFS network share. It is the baseline option and the right starting point for most deployments. Linux repositories using ReFS or XFS get block cloning support for fast synthetic full operations without actually reading and rewriting the data.
A Linux hardened repository is a standard Linux repository with immutability enabled. Backups written to it cannot be deleted or modified for the configured immutability period - not by Veeam, not by administrators, not by ransomware that compromises the backup server. The hardened repository uses single-use credentials to limit the backup server's ongoing access rights after the initial configuration.
An object storage repository connects Veeam to AWS S3, Wasabi, Azure Blob, Google Cloud Storage, or any S3-compatible endpoint. Object storage can serve as a SOBR Capacity Tier or Archive Tier, or in v13 as a direct backup target for certain job types including NAS backup jobs.
A Scale-Out Backup Repository (SOBR) is a logical repository that aggregates one or more standard repositories as performance extents and optionally attaches object storage as capacity or archive tiers. SOBRs solve the capacity growth problem - add another performance extent when you need more space instead of migrating to a larger repository.
Adding a Local or DAS Repository
Standard repositories are added in Backup Infrastructure > Backup Repositories by right-clicking and selecting Add Backup Repository. The wizard type you choose depends on the storage target.
Choose Direct Attached Storage or Network Share
Select Direct Attached Storage for local drives or DAS arrays attached to a Windows or Linux server. Select Network Attached Storage for SMB or NFS shares. For NFS shares, the Veeam server or a managed Linux server needs NFS client access to the share path.
Select the Server and Path
Choose the managed server that will host the repository. The server must already be in the managed server list. Specify the path where backup data will be stored. For Linux repositories on XFS or ReFS volumes, Veeam automatically detects the filesystem and enables block cloning.
Set Concurrent Task Limits and Load Control
Configure the maximum number of concurrent tasks (simultaneous backup jobs writing to this repository). Set this based on the storage hardware's capability - spinning disks handle fewer concurrent tasks than SSDs. The load control setting limits how many tasks can use the repository concurrently to prevent I/O saturation. A starting point for spinning disk repositories is 2-4 tasks; SSD-backed repositories can handle more.
Adding a Linux Hardened Repository
Hardened repositories add immutability to the Linux repository. The server must be a dedicated Linux machine - you cannot harden a repository on a machine that serves other Veeam roles like backup proxy or backup server. The OS must be a supported Linux distribution (Ubuntu 20.04+, RHEL 7.2+, CentOS 7.2+, Debian 9+, SLES 12 SP4+).
Add the Linux Server Using Single-Use Credentials
Add the Linux machine to managed servers in Veeam using an account that has permissions to configure the repository. For a hardened repository, this account will be used only for the initial setup - after configuration, Veeam uses a non-privileged account with limited permissions for ongoing backup operations. Do not add the Linux machine with a persistent root credential if you want true hardening.
Configure the Repository with Immutability
When adding the repository via the Add Backup Repository wizard, select Hardened Repository. Specify the path (XFS or ReFS filesystem recommended for fast synthetic operations). Enable Make recent backups immutable for N days and set the immutability period. Veeam sets the Linux file immutability flag on backup files - even root cannot delete them during this period without rebooting into a different runlevel. Set the period to match your recovery window requirements - typically 7 to 30 days at minimum.
Once immutability is set on a backup file, it cannot be shortened or removed without going to the Linux OS level. If you set an immutability period of 30 days and then need to reclaim space urgently, you cannot delete those files for 30 days. Size the repository conservatively relative to the expected data growth during the immutability window, and test the capacity math before production use.
Adding Object Storage Repositories
Object storage repositories are added in Backup Infrastructure > Backup Repositories > Add Backup Repository > Object Storage. The wizard branches based on the provider type. The core steps are the same across providers - credentials, bucket selection, and folder configuration - but the authentication mechanism differs.
| Provider | Authentication | Immutability Support |
|---|---|---|
| AWS S3 | Access key / secret key, or IAM role | Yes - S3 Object Lock |
| Wasabi | Access key / secret key | Yes - Wasabi Object Lock |
| Azure Blob Storage | Storage account / access key, or Azure AD service principal | Yes - Azure Blob immutability policies |
| Google Cloud Storage | Service account JSON key | Yes - object retention policy |
| S3-compatible (generic) | Access key / secret key | Depends on provider |
Select the Provider and Enter Credentials
Choose your object storage provider. For AWS, enter the access key ID and secret access key for an IAM user with the minimum required S3 permissions (s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket, and s3:GetBucketLocation on the target bucket). For Wasabi, the same permission model applies. For Azure, provide the storage account name and access key or configure a service principal.
Select the Bucket and Folder
Choose the bucket from the list. Create a dedicated folder within the bucket for Veeam backup data - do not point Veeam at the bucket root if other processes also write to the same bucket. The folder name becomes part of the backup storage path and cannot be changed after data is written without breaking the repository reference.
For Wasabi, note the regional endpoint selection matters for performance and compliance. Always select the endpoint that matches the region where your bucket is located.
Enable Immutability (Recommended)
If the bucket has Object Lock enabled (or the Azure equivalent), check Make recent backups immutable for N days in the repository configuration. For AWS and Wasabi, the bucket must have Object Lock enabled before you can configure immutability in Veeam - you cannot enable Object Lock on an existing bucket that was created without it. Create buckets with Object Lock enabled from the start if you intend to use immutability.
Configuring a Scale-Out Backup Repository
SOBRs are configured in Backup Infrastructure > Scale-out Repositories by right-clicking and selecting Add Scale-out Backup Repository. The wizard walks through performance extents, placement policy, capacity tier, and archive tier.
Before starting the SOBR wizard, ensure all repositories you plan to add as performance extents are already added to the Veeam infrastructure. A repository that is in active use by another job cannot be added as an extent mid-operation - schedule the SOBR configuration when no active jobs are running against the target repositories.
Name and Description
Give the SOBR a descriptive name. This name appears in all job configurations and in the Veeam console tree. Choose a name that reflects the purpose or location - Primary-SOBR-Site1 or Production-SOBR - something that remains meaningful as the environment grows.
Add Performance Extents
Click Add and select the repositories to include as performance extents. These are the repositories where active backup data lives. You can add Windows repositories, Linux repositories (including hardened repositories), deduplication appliance integrations, and even object storage repositories as performance extents in v13. Each extent retains its individual capacity and settings; the SOBR presents their combined capacity as a single logical pool.
Once a repository is added as a SOBR extent, it is no longer available as a standalone repository target. Jobs must be targeted at the SOBR, not at the individual extents directly.
Configure the Placement Policy
Choose between Data Locality and Performance placement policies.
Data Locality keeps all backup files belonging to the same backup chain on the same extent. Full and incremental files for a given VM stay together. This is simpler to manage and the right choice when extent failure isolation is more important than maximizing write throughput. If one extent goes offline, only the backup chains stored on that extent are affected.
Performance splits full backup files and incremental backup files onto different extents. Full backups on one extent, incrementals on another. This can improve transformation performance on certain storage types. The tradeoff is that if either extent in the pair goes offline, the backup chain is broken and jobs fail. Only use Performance mode when all extents are on reliable, highly available storage.
Optionally enable Perform full backup when required extent is offline for Performance mode - this triggers an active full backup rather than a failure if the extent holding an incremental file is unavailable.
SOBR Placement Policies
Within the placement policy, Veeam also lets you specify which extents receive which backup files. This is configured at the individual job level rather than the SOBR level - when targeting a SOBR, the job can be pinned to specific extents or allowed to use any available extent based on free space.
At the SOBR level, enable the Limit the maximum number of tasks per extent option to prevent any single extent from becoming a bottleneck when multiple jobs run simultaneously. This distributes concurrent write load across extents rather than queuing everything at the first available one.
Veeam recommends no more than 16 active extents in a single SOBR performance tier. Above this limit, metadata overhead and extent selection logic can degrade performance. If you need more capacity, use a second SOBR rather than a single SOBR with many extents.
Adding a Capacity Tier
The Capacity Tier attaches an object storage repository to the SOBR for automated off-site data movement. At the Capacity Tier step of the SOBR wizard, select Extend scale-out backup repository capacity with object storage and choose the object storage repository from the dropdown.
Two data movement modes are available and they are independent of each other - you can enable both simultaneously.
Copy backups to object storage as soon as they are created sends a copy of each new restore point to the Capacity Tier immediately after it is created on the performance extent. The performance extent retains its copy as well. This is the safest mode - every restore point exists in two places from the moment it is created. The tradeoff is increased object storage write costs for environments with high backup frequency.
Move backups to object storage as they age out of the operational restores window moves inactive backup chains - chains that have aged beyond the operational restore window - from performance extents to the Capacity Tier. The data leaves the performance extent and lives only in object storage after the move. The move is performed by an automated offload session that runs every 4 hours. Restores from moved data work directly from object storage without requiring the data to be copied back first, though restore performance is limited by object storage retrieval speed.
To encrypt data before it is uploaded to the Capacity Tier, check Encrypt data uploaded to object storage and provide a password. This is separate from any job-level encryption already in place - enabling it here adds a second encryption layer on top. See the encryption article in this series for guidance on when double encryption is appropriate versus redundant.
The Capacity Tier offload window controls when data movement is permitted. Configure this window to avoid overlapping with active backup windows - Veeam offload sessions running concurrently with active backup jobs increase load on the performance extents. Set the permitted window to off-peak hours when backup jobs are not running.
SOBR Limitations Worth Knowing
A few SOBR limitations that regularly catch people out in production:
A repository that is already added as an extent to one SOBR cannot be added to a second SOBR. Object storage repositories also cannot be shared - the same bucket/folder combination cannot serve as a Capacity Tier for two different SOBRs simultaneously.
SOBRs do not support rotated drives. If an extent is configured with rotated drive support, the SOBR ignores that setting and treats it as a standard extent. This means SOBR is not an appropriate target if your disaster recovery strategy involves physically rotating drives between sites.
SOBRs cannot be used as the cache repository for NAS backup jobs or as an archive repository for unstructured data backup jobs. If you need SOBR for VM backups and a separate target for NAS backups, they need different repository objects.
When using multiple S3-compatible providers (not AWS, not Wasabi - generic S3-compatible) in the same SOBR tier, one of the repositories must be in sealed mode. Sealed mode means it accepts no new data but remains accessible for restores. This is a constraint of the S3-compatible metadata handling and does not apply to AWS S3 or Wasabi.
Upgrading from v12
Repository configurations carry forward from v12 to v13 without changes. Standard repositories, hardened repositories, object storage repositories, and SOBR configurations all survive the VBR upgrade intact. Existing data remains readable and jobs continue targeting the same repositories after the upgrade.
The main repository capability to evaluate post-upgrade is the Archive Tier, which was introduced in recent v12 releases but is more fully developed in v13. The Archive Tier attaches a lower-cost object storage target (or on-premises object storage) below the Capacity Tier for long-term retention of backup data that needs to be kept but will almost never be accessed. If your retention requirements include multi-year data preservation at lower cost, the Archive Tier in v13 is worth reviewing.
Decision Reference
| Scenario | Recommended Repository Type | Notes |
|---|---|---|
| Single-site primary backup, standard workloads | Linux repository on XFS or ReFS | Block cloning for fast synthetics. Good baseline. |
| Ransomware protection required on-premises | Linux hardened repository | Enable immutability. Dedicated machine only. Size immutability period carefully. |
| Primary backup with cloud offsite copy | SOBR with local performance extents + object storage Capacity Tier | Enable Move or Copy mode based on retention and restore RTO requirements. |
| Multi-site, growing environment, capacity management | SOBR with multiple performance extents | Add extents as capacity grows. No data migration required. |
| Cloud-native or cloud-first deployment | Object storage as primary or SOBR performance extent | v13 allows object storage as performance extent for supported job types. |
| Long-term retention at low cost | SOBR with Capacity Tier + Archive Tier | Move aged data through tiers automatically. Restores from archive are slower. |
| Deduplication appliance target | Standard repository with dedup appliance integration | Disable job encryption. Use appliance hardware encryption post-dedup. |
- Added a standard backup repository on Linux with XFS or ReFS for block cloning support
- Optionally configured a Linux hardened repository with immutability for ransomware protection
- Added object storage repositories for AWS S3, Wasabi, Azure Blob, or S3-compatible targets
- Created a Scale-Out Backup Repository with performance extents and placement policy configured
- Attached a Capacity Tier to the SOBR and configured Move or Copy mode with an offload window
- Reviewed SOBR limitations and confirmed repository configuration is compatible with your job types
- Targeted at least one production backup job at the configured SOBR and verified it completed
Repository architecture is the part of Veeam infrastructure that is hardest to change after data is in it. Adding performance extents to a SOBR is easy. Changing which repositories are extents of which SOBR, or migrating data between SOBRs, is not. The right time to think about the three-tier model - performance, capacity, archive - is before the first backup runs, not after the first disk fills up. If object storage is in your eventual architecture, build the SOBR with that intent from day one rather than retrofitting it later.