The Unraid Docs and the r/Unraid subreddit have been a treasure trove of information, but I'm still no closer to knowing what's the optimum configuration for my mix of HDDs and SSDs. I'm hoping this community can help me with some expert suggestions. My main goal for setting up my home server is to act as a media server and store family documents/photos/videos. I chose Unraid because I already had a mix of HDDs and SSDs, of varying sizes.

These are the drives I can put into my server:

2x 16TB HDD

1x 10TB HDD

1x 8TB HDD

1x 8TB SATA SSD

1x 4TB SATA SSD

2x 2TB SATA SSD

1x 1TB NVMe SSD (think I will put this in my workstation instead of my server, unless there is a good reason otherwise)

I initially thought it would be as simple as chucking everything into a single array, with one of the 16TB HDDs as a parity drive. Then I read about cache pools and how they can improve write speeds. Then I also read that putting SSDs into an array would be suboptimal at best, and unsupported at worst. My main priority is to maximise capacity - I currently have about 35-40TB of data which I intend to store on my Unraid server. I'm okay with the minimum amount of redundancy - that's why I was okay having just the single 16TB parity drive. Having a cache would be cool too, if possible for my configuration.

Any and all suggestions for an optimum configuration for my setup are welcome.

HDDs in array with 16TB parity.

SSDs in the array can only be written at parity speed and cannot be trimmed, so better if they are in pools outside the array.

2x2TB SSDs could be a mirror for your Docker/VM related shares - appdata, domains, system.

The 4 or the 8 should be more than enough for caching writes.

6 hours ago, trurl said:

HDDs in array with 16TB parity.

SSDs in the array can only be written at parity speed and cannot be trimmed, so better if they are in pools outside the array.

2x2TB SSDs could be a mirror for your Docker/VM related shares - appdata, domains, system.

The 4 or the 8 should be more than enough for caching writes.

Thanks, that sounds like a good idea.

Someone on reddit also suggested:

Unraid Array: 1x16TB Parity, all other HDD as array disks; 34TB usable, fully protected

Cache Pools:

• POOL #1 - btrfs raid1 of the 1x8TB + 1x4TB + 2x2TB. 8TB of usable space, fully protected. Use for appdata, system, domains, Docker/VM related shares.

• POOL #2 - single 1TB nvme SSD and use as an array cache for downloads / data, etc.

Do you see any issues with this?

none.

however I'm pro zfs and pool only setups.

Review:
https://www.youtube.com/watch?v=UR5RCItyCsw

Some Q/A per your post:

First: clear up the big misconceptions

SSDs in the Unraid array

You read correctly:

• SSDs should NOT go in the traditional Unraid parity array

• Trim + parity don’t mix

• Performance is worse, not better

Ideally SSDs belong in pools, not the array.

Cache pools ≠ just “cache” anymore

In modern Unraid, pools are:

• Full-fledged storage tiers

• Can be Btrfs or ZFS

• Can host appdata, VMs, media staging, photos, etc.

You are no longer limited to a tiny “cache disk”.

ZFS is now first-class in Unraid

This is the key unlock for your setup.

ZFS gives you:

• Checksumming (bit-rot protection)

• Snapshots (huge for family photos/docs)

• Better SSD pooling behavior

• Much clearer performance characteristics

For a new Unraid user in 2026, ZFS pools are no longer “advanced only”. They’re recommended when the disks make sense.

Your goals (translated into storage design)

From what you said, your priorities are:

1. Maximize usable capacity (you already have ~35–40 TB)

2. Single-parity is fine

3. Good write speed

4. Safe storage for irreplaceable data

5. Not fragile or weird

Good news: your disk mix is actually excellent for a hybrid Unraid + ZFS layout.

Recommended High-Level Design:

Layer	Purpose
Array (HDDs)	Bulk media + large cold storage
ZFS SSD pool	Fast, safe storage for photos, docs, appdata
Optional NVMe	Scratch / workstation (or later server upgrade)

So here is my Concrete Recommended Configuration

1. Unraid Array (HDDs only)

Use this for:

• Movies

• TV shows

• Backups

• Large archives

Drives:

• Parity: 1 × 16 TB HDD

• Data:

  • 1 × 16 TB HDD

  • 1 × 10 TB HDD

  • 1 × 8 TB HDD

Resulting usable capacity:

16 + 10 + 8 = 34 TB usable

This already holds most of your existing data.

Why this works:

• Parity must be ≥ largest data disk: https://docs.unraid.net/category/manage-storage/

• HDD array excels at large sequential reads (media)

• Simple, well-understood, very stable

* Do not put SSDs here

---

2. Primary SSD Pool — ZFS Mirror (important data)

This is where ZFS shines.

Drives:

• 2 × 2 TB SATA SSD → ZFS mirror

Usable: 2 TB
Redundancy: Yes (1-disk fault tolerant)

Use for:

• Family photos

• Documents

• Personal videos

• Nextcloud / Immich / photo apps

• Anything you cannot re-download

Why this is ideal:

• ZFS checksums protect against silent corruption

• Snapshots protect against accidental deletion/ransomware

• Mirror keeps it simple and fast

This pool becomes your “gold tier” data. to copy into for deep stroage / use (immich settup)

---

3. Secondary SSD Pool — ZFS Stripe (performance + capacity) raidz1

You still have:

• 8 TB SATA SSD

• 4 TB SATA SSD

These do not mirror cleanly, so don’t force it.

Recommended:

• Single ZFS pool using both disks as individual vdevs (striped)

Usable: ~12 TB
Redundancy: ❌ none (acceptable by design)

Use for:

• Media staging

• Downloads

• Transcodes

• Docker appdata (with backups)

• Scratch space

Why this is okay:

• ZFS still gives checksumming

• Data here is replaceable

• Massive speed boost over HDD array

• You keep maximum capacity

If a disk dies here → inconvenience, not disaster.

---

4. NVMe SSD (1 TB)

Your instinct is correct.

Best choice:

• Put it in your workstation

Unless:

• You plan on running heavy VMs

• Or lots of real-time transcoding

• Or want a future L2ARC/SLOG experiment (not needed yet)

Unraid doesn’t benefit enough from a single small NVMe to justify pulling it from your desktop.

---

📁 How data should flow (important)

Set your shares examples like this:

Share	Location	Notes
media	HDD array	No cache
photos	ZFS mirror pool	Snapshots enabled
documents	ZFS mirror pool	Snapshots
appdata	SSD striped pool	Backed up nightly
downloads	SSD striped pool	Mover to array

Unraid handles this beautifully once shares are set correctly. user script plugin and some scripts on the forum to assist with data movement and deep storage...

---

So, About redundancy & backups (real talk)

Parity ≠ backup. ZFS mirror ≠ backup.

For irreplaceable data:

• ZFS snapshots (daily/weekly)

• External backup (USB or cloud)

• Even a cold HDD rotated monthly is enough

You don’t need RAID-Z2 or dual parity for home use unless uptime is critical.

I would actual recommended multiple pools of zfs raid z1:

Beginner-safe ZFS-first Unraid design with two RAID-Z1 groups, plus a practical Docker stack (Immich-centric) that won’t paint you into a corner later.

This assumes Unraid 6.12+ with native ZFS support.

High-level architecture (what you’re building)

You will have:

1. ZFS Pool A (RAID-Z1, HDDs) → bulk media + archives

2. ZFS Pool B (RAID-Z1, SSDs) → photos, documents, Docker data

3. Docker stack → Immich + media services

4. Snapshots + scrubs → data integrity and recovery

This avoids the legacy Unraid parity array entirely and gives you:

• End-to-end checksumming

• Snapshots

• Predictable performance

• Simple mental model

Example:

ZFS Pool Layout (recommended)

Pool 1: tank_media (HDD RAID-Z1)

Disks

• 16 TB HDD

• 10 TB HDD

• 8 TB HDD

Layout

• ZFS RAID-Z1 (1-disk parity)

Usable capacity

• ~18 TB usable (smallest disk × (n-1))

Purpose

• Movies

• TV shows

• Large videos

• ISO / archives

• Anything replaceable or re-downloadable

Why this works

• RAID-Z1 is fine for 3 disks

• Sequential media workloads are ideal for HDD ZFS

• One-disk failure tolerance

---

🟩 Pool 2: tank_ssd (SSD RAID-Z1)

Disks

• 8 TB SATA SSD

• 4 TB SATA SSD

• 2 TB SATA SSD

⚠️ Yes, mismatched sizes are okay — ZFS will normalize to the smallest disk (2 TB).

Usable capacity

• ~4 TB usable

Purpose

• Immich photos/videos

• Documents

• Appdata

• Databases

• Anything irreplaceable

Why RAID-Z1 here

• SSDs fail silently more often than HDDs

• RAID-Z1 + ZFS checksums is vastly safer than Btrfs cache

• Still much faster than HDDs

• With future replainge the smallest disk over time to increase storage...

  • Assuems future expansion to mathc disk sizes latter....

---

Spare drives (recommended)

• 1 × 16 TB HDD → cold spare / offline backup

• 1 × 2 TB SSD → future mirror, hot spare, or app expansion

• Or l2arc and side setups for zfs metadata...

---

Dataset design (very important) example...

Create datasets, not one giant filesystem.

On tank_media

tank_media/media
tank_media/movies
tank_media/tv
tank_media/downloads

Properties:

• compression=lz4

• atime=off

• No snapshots needed (optional)

---

On tank_ssd

tank_ssd/photos
tank_ssd/documents
tank_ssd/appdata
tank_ssd/immich
tank_ssd/postgres
tank_ssd/backups

Properties:

• compression=lz4

• atime=off

• Snapshots ENABLED

---

Snapshot policy (simple & safe)

For tank_ssd datasets:

• Hourly snapshots (24h retention)

• Daily snapshots (14–30 days)

• Weekly snapshots (3 months)

Use ZFS Master plugin or Sanoid(3rd party install).

This is huge protection against:

• Accidental deletes

• Bad Docker updates

• Ransomware

---

Docker stack (Immich-focused)

All Docker data lives on tank_ssd/appdata.

Brandon Martino - Personal Site

Immich-on-Unraid-CA-Docker

Brandon Martino - Personal Site

Some Core containers example

FOr Photos Immich (self-hosted photos)

• Image: ghcr.io/immich-app/immich-server

• Uploads: tank_ssd/immich

• DB: separate Postgres container

Immich containers:

• immich-server

• immich-microservices

• immich-machine-learning

• postgres

• redis

Immich benefits heavily from:

• SSD I/O

• ZFS snapshots

• Large datasets

---

Media stack (optional but common)

I recommend plex / *Ars stack...

App	Purpose
Plex / Jellyfin	Media streaming
Sonarr	TV automation
Radarr	Movie automation
Prowlarr	Indexer management
qBittorrent	Downloads

Media flow:

Downloads → tank_media/downloads
Processed → tank_media/movies / tv

---

Infrastructure containers (recommended)

*Contained and controlled is you use the docker compose guide posted above...

Container	Why
MariaDB / Postgres	Databases
Redis	Immich, caching
Nginx Proxy Manager	HTTPS
Watchtower (optional)	Auto updates
Duplicati / Kopia	Backups

---

Unraid plugins you should install

Plugin	Why
ZFS Master	Scrubs, monitoring
CA Backup / Restore Appdata	Docker safety
Fix Common Problems	Prevent mistakes
User Script Plugin	Cron and custom user scripts
tips and tweaks	general helpful info for the eunriad web ui.

---

ZFS maintenance schedule

Some scripts:
*https://forums.unraid.net/topic/178033-bmartino1-user-scripts/

• Scrub: monthly (both pools)

• SMART tests: monthly

• Snapshot pruning: automatic

• Backups: at least one offline copy

---

Why this beats “classic” Unraid for your case

Ditch the standard unraid array go pool disk groups only.

Classic Array	ZFS Pools
No checksums	End-to-end integrity
Parity ≠ corruption detection	Silent corruption detected
Cache complexity	Clean tiered pools
Limited snapshots	Native snapshots

You still keep Unraid’s Docker/UI strengths — just with a modern storage backend.

---

My Final verdict

This setup:

• Maximizes data safety

• Is new-user safe

• Uses ZFS where it matters

• Avoids SSD-in-array footguns

• Scales cleanly later

If you want next steps, I can:

• Map this exactly to Unraid UI clicks

• Generate docker-compose / CA templates

• Design a backup rotation plan

• Help size RAM for ZFS ARC

Pro cons to each.