Pick a layout. See the physics.

What the lab is trying to teach you

Parity is an investment, not a loss. The drives assigned to parity are what stand between a routine drive replacement and a full restore from the offsite copy. RAIDZ2 commits two drives per vdev in exchange for the ability to absorb two simultaneous failures without data loss.

Wide vdevs maximize capacity; smaller vdevs are more forgiving when something fails. A single 18-wide RAIDZ3 yields the largest usable figure. Three 6-drive RAIDZ2 vdevs yield a smaller one — but a rebuild touches six drives instead of eighteen, the pool has three times the vdev IOPS, and growth is a ten-minute zpool add rather than a replacement system. That's why every Hardened Repository is built from the same 6-drive module.

Gigabits are not gigabytes. Network gear is sold in bits; data moves in bytes — an eight-to-one difference before protocol overhead. "10G" networking really carries about 1.1 GB/s. Six nearline drives can already outrun it, and a handful of SSDs certainly will. Past that point, additional drives buy capacity and resilience — not visible speed — until the network grows too. This is why we ask about your switching before we quote drives.

The repository is only one link in the chain. Backup throughput is the minimum of three numbers: how fast the production side can be read, what the network carries, and what the repository can write. A common surprise in the field: the bottleneck is the busy production datastore you're copying from, not anything on the backup side. The lab models all three so you can see which one is actually holding your window — buying a faster repository doesn't help if the source can't feed it.

Fulls read everything; incrementals read only what changed. A full backup walks every byte of production, which is why the full-backup figure above is measured in hours. After that, Veeam uses the hypervisor's Changed Block Tracking (CBT): the hypervisor keeps a running map of which blocks have been written since the last backup, so the nightly job reads just those blocks — typically a few percent — and finishes in minutes. The catch is what happens after the window closes: merges, synthetic fulls, and health checks are built on the repository from restore points already there. No production reads, but heavy repository I/O — which is why an all-flash landing zone (our TNV24F), paired with a spinning-disk unit for retention via a backup copy job, is how we run our own backups when the window is tight.

Restore is where repository speed actually pays. If the source and network cap your backups, a faster repository won't shorten the window — but restores run the chain in reverse, and now the repository is the source. Two very different restore jobs: a streaming full restore moves data at the sequential rates above, but instant recovery — running VMs directly off the repository while you rebuild — is random I/O. Under random load, a RAIDZ vdev behaves like a single drive regardless of width: an 18-wide stripe of spinners boots VMs at one drive's IOPS. Three 6-drive modules triple that. Mirrors multiply it further. Flash makes the question disappear — which is why the all-flash tier is quoted in minutes of RTO, not gigabytes per second. When someone sells you backup storage by the terabyte without asking about your restore expectations, this is the paragraph they're hoping you haven't read.

Every layout here is a legitimate engineering choice. A wide RAIDZ1 maximizes usable capacity, and for some workloads that's the right call. Our practice is simply to make sure the rebuild-window risk is understood and documented before any configuration ships — that conversation is part of every design we deliver.