RAID Configuration for Proxmox VE

RAID Options in Proxmox VE

Proxmox VE gives you three distinct approaches to disk redundancy: hardware RAID controllers, ZFS software RAID, and Linux mdadm software RAID. Each has meaningful trade-offs in performance, flexibility, and management overhead. Choosing the wrong one can cost you data, performance, or money — so understanding the differences before you build matters more than it does in most other decisions.

Hardware RAID vs Software RAID

Hardware RAID

A dedicated RAID controller (like a Dell PERC or Broadcom MegaRAID) handles all parity calculations and disk management in hardware. Proxmox sees a single virtual disk and has no knowledge of the individual drives behind it.

Advantages: Offloads CPU from parity calculations, battery-backed cache protects against power loss, well-tested in enterprise environments.

Disadvantages: If the controller dies, you need an identical (or compatible) replacement to read your array. You cannot use ZFS features like checksumming and self-healing. The controller is a single point of failure. Consumer-grade "fake RAID" controllers (common on desktop motherboards) should be avoided entirely — they offer no real benefit over software RAID.

ZFS Software RAID (Recommended for Most Users)

ZFS manages RAID entirely in software, using your CPU for parity calculations. Proxmox has first-class ZFS support — you can create pools during installation or add them later.

Advantages: Checksumming detects and corrects silent data corruption. No proprietary controller dependency. Snapshots, compression, and send/receive are built in. Drives can be moved to any system with ZFS.

Disadvantages: Higher RAM usage (1 GB base + ~1 GB per TB of storage is a common guideline). CPU overhead for parity, though negligible on modern processors. RAID-Z expansion (adding drives to an existing vdev) only became available in OpenZFS 2.3+.

mdadm Software RAID

Linux's traditional software RAID. Reliable and well-understood, but lacks ZFS's data integrity features.

Advantages: Low resource overhead. Works with any filesystem. Simple to set up and manage. Supports online expansion and reshape.

Disadvantages: No checksumming — silent corruption goes undetected. No built-in snapshots (depends on LVM or filesystem-level snapshots). Less integrated with Proxmox than ZFS.

RAID Levels Comparison

Creating ZFS RAID Pools in Proxmox

ZFS pools can be created through the Proxmox web interface (Disks > ZFS) or the command line. The CLI gives you more control:

# Mirror (2 disks, equivalent to RAID 1)
zpool create tank mirror /dev/sda /dev/sdb

# RAIDZ1 (3+ disks, equivalent to RAID 5)
zpool create tank raidz /dev/sda /dev/sdb /dev/sdc

# RAIDZ2 (4+ disks, equivalent to RAID 6) — recommended
zpool create tank raidz2 /dev/sda /dev/sdb /dev/sdc /dev/sdd

# Striped mirrors (4 disks, equivalent to RAID 10)
zpool create tank mirror /dev/sda /dev/sdb mirror /dev/sdc /dev/sdd

After creating the pool, add it as a Proxmox storage resource:

# For directory-based storage
pvesm add dir tank-storage --path /tank --content images,rootdir,vztmpl,iso,backup

# For ZFS-native storage (zvols for VMs, datasets for containers)
pvesm add zfspool tank-storage --pool tank --content images,rootdir

Rebuild Times and Why They Matter

When a disk fails, the array rebuilds (resilvers) using data from the remaining drives. During this window, your data is vulnerable. With modern large drives, rebuild times can be surprisingly long:

• 1 TB SSD mirror: ~30 minutes to resilver
• 4 TB HDD in RAIDZ1: 6-12 hours depending on pool usage
• 16 TB HDD in RAIDZ1: 24-48+ hours — during which a second failure destroys the pool

This is why RAIDZ1 is increasingly discouraged for large disks. If you are using drives larger than 4 TB, RAIDZ2 (or mirrors) is strongly recommended. The extra parity disk costs less than the data you would lose during a double-failure event in a multi-day resilver.

Performance Considerations for VM Storage

Random I/O performance matters most for VM workloads. Here is how the RAID types compare for typical VM disk operations:

• Mirrors and RAID 10 deliver the best random write IOPS because writes only go to two disks (the mirror pair). This makes them ideal for VM storage.
• RAIDZ1/Z2 suffer from the "RAID 5 write penalty" — every small random write requires reading the old data and parity, computing new parity, and writing both. For database VMs, this can cut IOPS dramatically.
• Adding a SLOG (ZFS Intent Log) device — a fast, power-safe NVMe — can significantly improve synchronous write performance on RAIDZ pools.

# Add a SLOG device to an existing pool
zpool add tank log /dev/nvme1n1p1

Practical Recommendations

• 2-disk setup: ZFS mirror. Simple, fast, and reliable.
• 4-disk setup: Two mirrored vdevs (RAID 10 equivalent) for VM storage, or RAIDZ2 if capacity matters more than IOPS.
• 6+ disk setup: RAIDZ2 for bulk storage. Add a separate SSD mirror pool for VM disks if you need high IOPS.
• Always use ZFS over hardware RAID unless you have a specific enterprise requirement for controller-based RAID.

When managing RAID configurations across multiple Proxmox nodes, keeping track of pool health, resilver status, and disk assignments can get complex. ProxmoxR provides a consolidated view of your storage topology across all nodes, making it straightforward to spot degraded pools before they become critical.