Learn Veeam - Repository & Storage
This episode explores Veeam storage: Windows/Linux repositories, SMB/NFS, and S3 object storage, plus the Scale-Out Backup Repository (SOBR) with capacity tier. You will also understand dedup & compression (None, Dedupe-friendly, Local target) and integration with hardware deduplication appliances such as HPE StoreOnce and ExaGrid.
#Introduction
After the first successful job in episode 5, now we focus on the home for backups: repositories & storage. In episode 6 we dissect the types of repositories — Windows, Linux, SMB/NFS, and S3 object storage — then dedup & compression and hardware deduplication appliance integration.
The storage choice determines almost everything: backup speed, restore speed, cost per GB, and ransomware resilience. Choose wrong, and you will pay for it repeatedly in operations.
#Types of Backup Repositories
#Windows Repository
A folder on a Windows server (local or mapped drive). The simplest option: create the repository, Veeam installs the components and starts storing .vbk/.vib files there. Suitable for labs and Windows-first environments.
#Linux Repository
A folder on a Linux server — often the production choice for three advantages: performance (the Veeam Linux data mover is efficient), cost (Linux without storage licensing), and security — it supports hardened repositories (immutable) which we cover in episode 13. Add the Linux server as a Managed Server, then create the repository on its mount point.
$srv = Get-VBRServer -Name "backup01.lab"
Add-VBRBackupRepository -Name "LinuxRepo" -Path "/backups" -Server $srv#SMB / NFS Repository
A repository on an SMB (Windows) or NFS (Linux/NAS) share. Practical because storage is centralized and can be shared between servers — but consider: backup files are processed over the network, and without file-level immutable protection, SMB is generally more vulnerable to ransomware than a Linux repo. Use SMB for convenience, Linux/NFS for resilience.
#S3 Object Storage
Veeam v13 supports S3-compatible object storage as a full repository: AWS S3, Azure Blob, Google Cloud Storage, MinIO, Wasabi, and others. Data is stored as objects (not traditional files) — suitable for low cost, unlimited scale, and object lock (immutability — episode 13). Object storage is also the foundation of the SOBR capacity tier (episode 18).
#Scale-Out Backup Repository (SOBR)
SOBR is a container that combines several repositories into one namespace:
- Performance tier: fast repositories (local Linux) for active backups.
- Capacity tier: object storage for offloading old and cold data.
Think of SOBR as a storage pool: a job just points to one SOBR, and Veeam decides which new data goes to the performance tier, while old data is offloaded to the capacity tier according to policy. We cover the architecture and operations in detail in episode 18.
#Dedup & Compression
#Three Optimization Choices
Each job selects a dedup/compression level via Storage optimization:
- Local target — light dedup & compression; assumes local storage that is already deduplicated (or prioritizes backup speed). Suitable for simple repositories.
- LAN — a balance between dedup ratio and speed; the default for LAN environments.
- WAN — the highest compression to save cross-site bandwidth.
| Optimization | Dedup & compression | Speed | Bandwidth |
|---|---|---|---|
| Local target | Low | Highest | Efficient on the repo side |
| LAN | Medium | Balanced | Balanced |
| WAN | High | Lowest | Most efficient |
#Dedup Appliances: HPE StoreOnce and ExaGrid
Hardware deduplication appliances (HPE StoreOnce, ExaGrid, Dell Data Domain) integrate Veeam as a target repository. Veeam detects these devices and uses dedup-friendly techniques: because the appliance already deduplicates at the hardware level, Veeam lowers its own dedup (None/Dedupe-friendly) to avoid double dedup that wastes CPU and slows down transfer.
Veeam dedup + Appliance dedup = double CPU, slow transfer, little saved
Veeam dedup-friendly (None) + Appliance dedup = fast transfer, efficient CPUNote
Don't dedup twice. If your repository is a hardware deduplication appliance, set the job to Dedupe-friendly or None. Layered dedup makes backups slow and wastes CPU without meaningful space gains. The same rule applies when using natively deduplicated storage such as ZFS with dedup enabled.
#Choosing the Right Repository
Practical guidance:
- Lab / small: Windows repo or a simple Linux repo.
- Linux-based production: Linux repo (performance + can be hardened later).
- SaaS/off-site / cold data: S3 object storage via the SOBR capacity tier.
- Dedup HW (StoreOnce/ExaGrid): set optimization to Dedupe-friendly.
Warning
The repository is the second single point of failure after the hypervisor. Backups stored on the same disk as production data protect nothing against disk failure or ransomware. Episode 7 builds the second line of defense: backup copies and the 3-2-1 rule.
#Verifying Repositories
Get-VBRBackupRepository | Format-Table Name,Type,UsedSpace,Capacity -AutoSizeMake sure each repository shows the correct capacity and space.
#Closing
Key takeaways:
- Repositories can be Windows, Linux, SMB/NFS, or S3 object storage.
- The Linux repo is the production choice: performance + the path to a hardened repository.
- SOBR combines a performance tier (fast) and a capacity tier (cheap).
- Optimization: Local target, LAN, WAN — choose according to topology.
- Dedup appliances (HPE/ExaGrid): set Dedupe-friendly, never double dedup.
In the next episode, episode 7, we will cover data protection history: the 3-2-1 rule & retention — Daily/Weekly/Monthly/Yearly retention (GFS), KeepN policies, and Backup Copy Jobs to copy to a second (off-site) repository. Your data security foundation will become multi-layered!