Specifying a Veeam backup repository: hardware for a hardened, fast-restore target (UK 2026)

Plenty of guides tell you which backup software to buy. Far fewer tell you how to build the box the backups land on — and a badly-specified repository is where slow restores and broken immutability come from. This is how we spec a Veeam backup repository server for UK customers: hardened, fast to restore from, and sized for real retention.

Hardened repository data flow

Decide the repository type first

The hardware follows the repository design. A hardened Linux repository (immutable, XFS with fast-clone plus the immutability flag) on direct-attached storage is current best practice for an on-prem target; a Windows ReFS repository is the alternative; an S3 Object Lock target (on-prem object storage or cloud) adds an immutable capacity tier. The most resilient designs combine a fast on-prem tier with an immutable copy.

Capacity: size for change rate and retention

Repository capacity is driven by full backup size, daily change rate, retention points and Veeam's dedup/compression — not just "how much data do we have". Size the usable capacity for the full retention chain plus headroom, and remember immutability holds restore points for their full window, so they cannot be pruned early.

Storage layout: throughput and rebuild

Backup and (critically) restore throughput depend on the disk subsystem. For capacity HDD pools, choose a parity scheme that balances usable capacity against rebuild time on large drives (RAID 6 / dual-parity, not RAID 5, on big spindles). A flash landing/performance tier in front speeds ingest and Instant Recovery; an HBA in passthrough suits software-defined or hardened-Linux designs better than hardware RAID.

•Capacity tier: high-density HDD, dual-parity, sized for full retention
•Performance tier (optional): NVMe/SSD for fast ingest + Instant Recovery
•Controller: HBA passthrough for hardened-Linux/SDS; hardware RAID for traditional volumes
•Boot: separate mirrored device, isolated from the repository pool

Which repository type?

Hardening and immutability

For a hardened Linux repository: a dedicated box, single-use credentials, SSH locked down, no domain join, and Veeam's immutability flag set so restore points cannot be deleted or encrypted within the window. This is the layer that survives a domain-wide ransomware event — and it only works if the repository is genuinely separate from production identity.

Follow the 3-2-1-1-0 rule: keep an immutable copy and a verified, error-free restore test. The repository hardware is one part; the architecture around it is what makes it trustworthy.

Building the target

In practice this is a 2U storage-dense Dell PowerEdge or HPE ProLiant (or, at scale, an HPE Apollo capacity node) with an HBA, a large HDD capacity pool and an optional flash tier — or a purpose-built HPE StoreOnce dedupe appliance where you want turnkey. Build a repository target in our configurator, and pick the controller with our HBA/RAID guidance.

FAQs — Specifying a Veeam backup repository

Design

What hardware do I need for a hardened Veeam repository?

A dedicated server (not domain-joined) with direct-attached capacity storage, an HBA in passthrough, XFS with the immutability flag, and a separate mirrored boot device. Build one in our configurator, or use an HPE Apollo capacity node at scale.

How do I size repository capacity?

From full backup size × daily change rate × retention points, after Veeam dedup/compression, plus headroom — and remember immutable restore points are held for their full window and can't be pruned early. We'll size it with you when you scope a target.

Resilience

Does the repository make my backups ransomware-proof?

The repository is one layer. Immutability (the hardened Linux flag or S3 Object Lock) stops backups being deleted or encrypted in-window, but only if the box is genuinely separated from production identity. Pair it with 3-2-1-1-0, tested restores and broader cyber-security controls.