Unraid 7 brought a new "shiny" toy with ZFS pools, which I am keen to try it out. My current setup as follows:

• 12 HDD disks for media storage, 1 parity disk. All formatted as XFS

• 1 NVME as cache disk, XFS formatted, hosts appdata/dockers, VM, and *arr download directory (using mover to copy to array once per day)

The most obvious change and no-regret seems to change the formatting of my cache disk to ZFS as this seems to bring performance and security advantages. When doing so, I can also think of creating redudancy to it. A few questions:

1) I can buy a second NVME disk and mirror my current NVME to it. This would then be a ZFS pool with full redudancy. This seems straight foward. Alternatively, I could format one of my array disks as ZFS and then create a backup of my NVME drive to the array. This would make it double-protected (mirrored and parity), but I don't carae about this. Maybe it may make it slower though? Any thoughts among these two options?

2) If I were to format one of the array disks to ZFS to backup the cache disk per above, which array disk should I choose? A "movie disk" (with only large files with minimal writes) or a "tv disk" (with more smaller files also with minimal writes) or a "music / other disk" (with endless small files and more frequent reads). Or does it not matter? Or would it be even better to have a dedicated disk, in which case I can also just go with the mirrored ZFS pool.

3) I currently have docker, VM and scratch folders on the same NVME disk. Are there any advantages / needs to have them on different disks? If so, I could consider having 2 or even 3 NVME disks. One for dockers, one for the VM and one for the scratch files (arr downloads). I don't need the extra space, so all three things nicely fit on one disk now. I am curious though on any performance differences or other advantages I'd have if I were to separate them?

Thanks for any thoughts you may have!

Some Best Practices for a ZFS only Setup:

View ZFS Forum Info 

ZFS Unraid Docs

Edited September 16, 2025Sep 16 by bmartino1

q/a

Mirror vs. Backup-to-Array

• ZFS mirror (two NVMe drives):
  This is the cleanest, most robust setup. Your Docker/VM/scratch workloads will benefit from the performance of NVMe, and you’ll get redundancy at the filesystem level. If one NVMe dies, the other continues without downtime. Also, ZFS scrubs will ensure silent corruption doesn’t creep in.
  → This is the option I’d recommend if you care about uptime and performance.

• One NVMe + backup to array (ZFS disk in array):
  This adds complexity. You’d be mirroring your cache drive into a much slower spinning disk in the array. That disk would also be tied to parity writes if it’s in the array, which hurts performance. In practice, you’d never want your “live” Docker/VM workloads touching that slower disk. As a backup target it could work, but then you’d still want a snapshot/replication job, not a ZFS mirror.
  → Feels like extra moving parts for less benefit unless you really want a cold backup living on spinning rust.

Which Disk to Use if You Went That Route

If you did use an array disk as a backup target:

• It doesn’t really matter whether it’s a “movie,” “tv,” or “music” disk — ZFS datasets won’t care about file type.

• What matters is I/O pattern overlap. If you back up to a disk that’s otherwise idle (say, a movie disk), you won’t introduce contention during reads/writes from other services.

• But if you have the option, a dedicated disk outside the parity array (just as a ZFS pool member) would be better. That way you don’t drag down parity performance and can snapshot/replicate at full speed.

Splitting Dockers / VM / Scratch Workloads

• All-in-one NVMe (current setup):
  Totally fine for most home labs. ZFS datasets let you isolate and tune things (compression, recordsize, quotas) per dataset, so you can already optimize per workload without separate physical devices.

• Two or three NVMe drives:
  You might see marginal gains if you had extremely heavy simultaneous VM I/O and large Docker scratch downloads — but unless you’re hammering the drives constantly (e.g., Plex + multiple VMs + *arr unpacking at once), it’s overkill.

• Best compromise:
  Use one mirrored pair of NVMe drives as your ZFS pool. Inside it, create datasets for:

  • appdata / docker

  • VMs

  • scratch/downloads

  This way you can tune each dataset (e.g., disable compression on scratch, set larger recordsize for VM images, smaller for databases), but still keep redundancy and NVMe-level performance.

Some Practical Advice

1. Mirror the NVMe drives with ZFS. That’s the no-regret move.

2. Skip backing up to an array disk for redundancy. If you want backups, use ZFS replication (zfs send | zfs recv) on a schedule, but target something not latency-sensitive.

3. Keep workloads together on the NVMe mirror and separate them into ZFS datasets. That gives you flexibility without juggling hardware.

Wow, this is really great and super helpful. Appreciate you taking the time to share in such depth.

The path is clear. I will go with a mirrored ZFS pool. Great there is no issue per se in having dockers, scratch and VM on the same disk. That makes my life far easier.

I won't "hammer Plex" and also won't "hammer" a lot of arr unpacking. Typically, only one client streams from Plex (rare occasions 2) and there is also just regular streaming activity and not excessive. Also no crazy arr activity. However, my arr libraries are HUGE. So, the library files are also quite massive. Don't know how the arrs work and whether a large library impacts read/write activity to the disks. Just a regular folder scanning takes forever. And I can imagine the constant usenet searches and artist refresh (for the thousands of artists on lidarr) have some form of negative impact on something. Assume largely on the array though, so nothing to do with my cache disk?

With this additional info, any thoughts how to set up my mirrored cache disk? I probably should disable compression for all folders (no gain?). I don't know what recordsize is and how to set it. Or other settings?