If you’re building a home NAS in 2026, the single biggest decision you’ll make isn’t the drives — it’s the RAID level. Pick the wrong one and you’ll either waste half your capacity on redundant parity you don’t need, or lose everything when a second drive dies during a rebuild. This guide walks through the settings that matter on TrueNAS SCALE, Unraid, and OpenMediaVault, with exact values and the trade-offs behind each one.

What to prioritize, in order: your actual redundancy requirement first, then usable capacity, then write performance, then rebuild time. Most home users over-prioritize capacity and under-prioritize the scrub schedule, which is the setting most likely to silently save your data. Everything below assumes consumer-grade drives (8–24 TB CMR units) on a 2–6 bay system.

Setting Recommended value Why
RAID level (2 drives) RAID 1 (mirror) Only sane option; survives one drive failure, fast rebuilds
RAID level (3–4 drives) RAID 10 or RAIDZ2 RAID 10 for speed, RAIDZ2 for capacity with two-drive fault tolerance
RAID level (5–6 drives) RAIDZ2 (ZFS) or RAID 6 Two-drive tolerance; URE risk makes RAID 5/RAIDZ1 risky on large disks
Filesystem ZFS (OpenZFS 2.2+) Checksumming catches silent corruption; native scrubbing
Scrub schedule Monthly, on a low-usage day Detects bit rot before a second failure compounds it
SMART tests Short test weekly, long test monthly Early warning of pending drive failure
Sync writes Standard (enabled) Guarantees write integrity; disable only with a protected SLOG
Auto-expand pool Disabled Prevents accidental pool degradation when swapping drives
ARC max size Default (up to 50% RAM) Read caching helps; cap manually only on RAM-constrained boxes
Snapshot retention Hourly for 1 day, daily for 2 weeks Protects against ransomware and accidental deletion

Setting-by-Setting

RAID Level and Pool Layout

Exact value: Two bays: RAID 1 mirror. Three or four bays: RAID 10 (two mirrored pairs, striped) in TrueNAS via Storage → Create Pool → Data VDEVs → Mirror, adding two mirrors to the same VDEV group layout. Five or six bays: RAIDZ2 via Storage → Create Pool → Data VDEVs → RAID-Z2.

Trade-off: RAID 10 gives you 50% usable capacity and the best random IOPS, plus the fastest rebuilds (mirroring one drive to its partner). RAIDZ2 gives you (N−2) drives of usable capacity and survives any two simultaneous failures, but rebuilds are parity-based and slower, and random write IOPS are roughly one IOPS group per vdev. Never choose RAID 5, RAIDZ1, or RAID 0 for anything you care about — with modern 16 TB+ drives, an unrecoverable read error during a single-parity rebuild is a realistic way to lose the array.

Filesystem Choice

Exact value: OpenZFS. In TrueNAS SCALE it’s the only pool option; in OpenMediaVault 7, use the openmediavault-zfs plugin rather than mdadm/RAID 5. Choose Unraid only if you need mixed drive sizes and expansion one disk at a time — its parity protects against one disk failure by default (two with dual parity on Pro).

Trade-off: ZFS checksums every block, so it detects silent corruption that mdadm never will, and scrubs repair it from parity or mirror copies. The cost: RAM hunger (plan on 8 GB minimum, 16 GB comfortable) and no in-place shrinking of a pool.

Scrub Schedule

Exact value: Monthly. In TrueNAS: Data Protection → Periodic Snapshot Tasks / Scrubs → pool → Edit → Frequency: Monthly, Day: Sunday, Hour: 03:00. Keep the default enabled checkbox for “scrub at boot if overdue.”

Trade-off: Scrubbing reads every sector and costs I/O for hours on large pools, but a pool that never scrubs can have latent corruption sitting unrepaired until a drive dies and the rebuild surfaces it. Weekly scrubs wear drives marginally faster for no real gain on home workloads.

SMART Scheduled Tests

Exact value: Short self-test weekly, extended self-test monthly. In TrueNAS: Data Protection → SMART Tests → Add, set Type to Short, schedule every Sunday at 02:00; add a second task with Type Long, first Sunday of the month at 01:00. Set System Settings → Advanced → SMART reporting notifications to email you on any failure.

Trade-off: Extended tests on 20 TB drives can take 12+ hours and slow the pool, hence monthly. Short tests cost minutes and catch most developing failures.

Sync Writes / SLOG

Exact value: Leave sync at Standard (dataset-level setting in TrueNAS: Datasets → your dataset → Advanced → Sync: Standard). Only consider a dedicated SLOG device (a small, power-loss-protected NVMe mirror) if you run VMs or iSCSI and need fast sync writes. Media storage doesn’t need it.

Trade-off: Disabling sync (setting it to Disabled) speeds up NFS/VM writes but risks corruption on power loss. Never disable it system-wide; scope exceptions per dataset if needed.

Snapshots and Retention

Exact value: In TrueNAS: Data Protection → Periodic Snapshot Tasks → Add — Dataset: your shares dataset, Recursive: checked, Schedule: hourly, Lifetime: 24 hours. Add a second task: daily at 00:00, lifetime 2 weeks. Enable Snapshot Lifecycle pruning so expired snapshots delete automatically.

Trade-off: Snapshots are near-free (copy-on-write) but recursive hourly snapshots on a churn-heavy dataset consume space as deleted data stays referenced. Two weeks is a good ceiling for home use; monthly snapshots stretch to a quarter if you want archive rollback.

ARC / RAM Allocation

Exact value: Leave the ARC default (up to 50% of system RAM). Only set zfs_arc_max if the host also runs containers or a hypervisor: on Linux, add options zfs zfs_arc_max=8589934592 to /etc/modprobe.d/zfs.conf to cap at 8 GiB, then run update-initramfs -u and reboot.

Trade-off: A bigger ARC means hotter reads come from RAM, but starving the host of RAM causes instability. Cap, don’t disable.

By Hardware Tier

Low Tier (2–4 bays, 8 GB RAM, SATA)

Two drives: RAID 1 mirror on ZFS. Four drives: two striped mirrors (RAID 10) if you need write speed for working files, or a single RAIDZ2 vdev only if you have 8 GB RAM and can accept slower parity writes — honestly, on 8 GB, prefer mirrors. Scrub monthly, SMART as above, skip the SLOG and L2ARC entirely. Skip Unraid’s parity array on this tier if all your drives are the same size; ZFS mirrors are simpler and faster.

Mid Tier (4–6 bays, 16–32 GB RAM, SATA/NVMe boot)

Six drives: single RAIDZ2 vdev — this is the sweet spot for home NAS. Four drives: RAID 10 for mixed workloads (Plex + VMs + backups) or RAIDZ2 for maximum capacity. Add a 2-disk NVMe mirror for apps and VM datasets, keeping the spinning pool for bulk media. Scrub monthly off-hours; enable email alerts via System Settings → General → Email and test them with the Send Test Mail button.

High Tier (8+ bays, 32 GB+ RAM, HBA)

Use an LSI HBA in IT mode rather than a RAID controller’s onboard RAID — pass drives straight to ZFS. Two RAIDZ2 vdevs of six drives each (12 drives total) for a good capacity/performance/rebuild-time balance; avoid one giant vdev of 8+ drives, since per-vdev IOPS don’t scale with width. Add a power-loss-protected NVMe SLOG mirror if you run iSCSI. Keep vdev width at 6–10 drives, expand by adding vdevs, not replacing drives one at a time.

Common Mistakes

Running RAID 5 / RAIDZ1 on drives 8 TB or larger. What causes it: old advice from the days of 1–2 TB drives, where single parity was reasonable. How to check: in TrueNAS, Storage → pool → Edit VDEVs — if your data vdev shows “RAID-Z1,” you have it. What to do: back up everything, destroy the pool, and recreate as RAIDZ2 (or mirrors) via Storage → Create Pool, then restore. How to undo: you can’t convert in place — plan for a full restore window.

Never scrubbing, or scrubbing manually once and forgetting it. What causes it: scrubbing looks like it did nothing, so people assume it’s optional. How to check: Data Protection → Scrubs — if the last scrub is older than 60 days, you’re exposed; also run zpool status and look for “none requested” in the scrub line. What to do: enable the monthly schedule described above and run one scrub immediately. How to undo: disable the task if I/O impact proves problematic on very old hardware, but check zpool status output manually each month instead.

Assuming RAID is a backup. What causes it: marketing language around “data protection.” How to check: do you have a second, offline copy anywhere (external drive, cloud, another machine)? If no — RAID only protects against drive failure, not deletion, ransomware, fire, or a failed controller. What to do: add at least one snapshot schedule (instant rollback against ransomware) and one off-box backup, e.g. a nightly rsync task in TrueNAS via Data Protection → Rsync Tasks to an external USB drive, or cloud sync via Data Protection → Cloud Sync Tasks. How to undo: nothing to undo; keep both.

Buying SMR drives for a parity array. What causes it: SMR (shingled) drives are cheaper and often not clearly labeled. How to check: look up the exact model number on the manufacturer’s spec sheet — Seagate lists “SMR” vs “CMR” per model; WD red-labels SMR units. What to do: return or repurpose SMR drives for cold backup use only; rebuild a parity pool onto CMR drives (WD Red Plus, Seagate IronWolf, Toshiba N300 lines are CMR). How to undo: swapping SMR out for CMR is always safe; rebuilding onto SMR may take days or stall.

Using a hardware RAID controller’s onboard RAID with ZFS. What causes it: it seems “safer” to let the controller handle it. How to check: in TrueNAS, run camcontrol devlist or check Storage → Disks — if you see one giant “disk” instead of individual drives, the HBA/RAID card is hiding them. What to do: flash the controller to IT mode (LSI/Broadcom 9207/9300 series are common candidates; use the IT firmware from Broadcom’s site) or replace it with a plain HBA, then recreate the pool on raw drives. How to undo: flashing back to IR/RAID firmware is possible but rarely wanted.

FAQ

Is RAID 10 or RAIDZ2 better for a 4-bay home NAS?

For pure media storage with a few users, RAIDZ2 gives you 2 drives of usable capacity and two-drive fault tolerance. For mixed workloads — VMs, databases, photo libraries with lots of small writes — RAID 10’s random IOPS and fast rebuilds win, at the cost of only 50% usable capacity. If you’re unsure, mirrors are the more forgiving choice on smaller systems.

Do I need ECC RAM for a home NAS?

It’s genuinely useful but not mandatory. ZFS without ECC still checksums and detects corruption; ECC just prevents the host itself from writing corrupted data. If your platform supports it (most Intel W-series, AMD Ryzen with a compatible board), use it. If not, don’t lose sleep — checksumming plus scrubs still catch most issues.

How many drives can fail before I lose data?

RAID 1 or RAID 10: one per mirror pair. RAIDZ1/RAID 5: one total. RAIDZ2/RAID 6: any two, anywhere in the vdev. RAIDZ3: any three. These are simultaneous-failure tolerances — rebuild the array promptly after any failure, because a second failure during rebuild is the classic data-loss scenario.

Can I expand a ZFS pool later without destroying it?

Yes, by adding vdevs: Storage → pool → Add VDEV adds capacity immediately (data redistributes as it’s written, or use a manual zpool rebalance-style copy for even distribution). Since OpenZFS 2.2, RAIDZ vdev expansion exists but is slow and best treated as a last resort — planning your vdev width up front is still the right call.

Related guides