Good evening everyone,

I asked a few weeks ago whether Unraid was a good fit for my needs, and I’ve been reading up on it since then. I’m a beginner getting into homelabbing and self-hosting for the first time.

I’ve already built the server and I'm leaning into using Unraid, mainly because I believe my use case would benefit from being able to spin down disks. The hardware consists of:

• CPU: Intel Core i5-12600K

• MOBO: ASUS PRIME B760-PLUS D4

• RAM: 64GB DDR4 3200MHz

• CASE: Jonsbo N5 (12-bay hot-swap, currently 4 active via onboard SATA)

• HDD Array: 4x 24TB WD White Label (one for parity)

• NVMe: 2x 2TB WD Black SN850X + 1x 2TB Seagate FireCuda (if needed)
  

It was recommended that I consider virtualizing Unraid in Proxmox, but I have a few concerns. I understand the main advantages are service isolation and the ability to restore via snapshots. My understanding of the setup would be as follows:

I would virtualize Unraid in Proxmox and perform a full passthrough of the motherboard's SATA controller. I’d do the same for the two WD NVMe drives for the cache, which I plan to run in RAID1 for redundancy. This VM would handle all NAS functions.

On the other hand, I would need to create LXCs or VMs for the various services. This is where I have doubts about the best approach:

1. Using Docker inside Unraid: This is probably the easiest way once set up within Proxmox and offers the benefit of community templates. However, I’m worried this might defeat the purpose of isolation.

2. A second Unraid instance just for Docker: This would detach the NAS portion from the services while keeping Unraid’s ease of use for Docker. However, I believe this can't be done on a single license.

3. A single VM/LXC for Docker: I would use a Linux distro, likely Debian from what I see usually recommended, and manage everything with Portainer or a similar tool. I’m unsure if I would need the third NVMe since the others would be passed to Unraid.

4. Multiple VMs/LXCs for each service: I could group similar services, such as Immich + Paperless, or the Arr stack + Jellyfin, or AdGuard + Unbound. This offers the most independence but might be overkill to manage. Again, unsure on how to manage disk space.

What do you guys think? Am I missing anything, or perhaps making things more complex than necessary? I’m a bit lost on where to start and unsure if the complexity is worth it over a bare-metal Unraid setup. I also have general issues understaing how the hardware is managed with multiple VM/LXC running.

Lastly, I’ve seen that Unraid will soon be bootable directly from NVMe. Should I wait for this release before starting?

Any general advice is welcome.

Thanks in advance!

Bare-metal.

https://forums.unraid.net/topic/179219-guide-proxmox-virtualize-unraid-experimental-with-v7/

Edited January 24Jan 24 by bmartino1

unriad supports both VMs and LXCs

...

that said since unraid v6 I haven't had any really issues with virtualized Unriad. But the Devs really don't want it in a VM...

unriad is docker king and has great CA / forum / docker support. That said Unriad is not for everyone and a lot of what it does can be done on other systems such as proxmox. Turenase scale, OMV etc...

Proxmox is Great for Virtual Machines and some LXC systems via the PVE help scripts.
https://community-scripts.github.io/ProxmoxVE/

which is great for a new person to get started and learn.

But to run both you need quite a bit of system resources to split and use to run multiple os which can get complex fast. Sometimes requiring additional and specialized hardware.

For a beginner with your hardware and goals: run Unraid bare-metal first.
Skip Proxmox-for-now. You’re not missing out on anything critical, and you’ll learn much faster with fewer moving parts.

Model A — Unraid as the platform (recommended for you)

• Unraid is the OS

• Storage, Docker, light VMs all live together

• You get:

  • Disk spin-down

  • Dead-simple Docker UX

  • Community Apps (huge win for beginners)

  • Minimal hardware abstraction to understand

Model B — Proxmox as the platform

• Proxmox controls everything

• Unraid becomes “just another VM”

• You must understand:

  • PCIe passthrough

  • IOMMU groups

  • Storage layers (ZFS/LVM → VM disk → filesystem)

  • Backup strategies across hypervisor boundaries

This model is powerful, but it’s not beginner-friendly, and it does not actually reduce risk early on.

---

Your hardware is already perfect for Unraid

You’ve got an ideal Unraid box:

• i5-12600K → plenty of cores for Docker + Plex/Jellyfin transcoding

• 64 GB RAM → massive headroom

• Large HDD array → Unraid parity model shines here

• Multiple NVMe drives → perfect cache/appdata layout

Unraid’s value proposition (mixed disks + spin-down) is weakened when virtualized.

---

Q/A

1. “Should I virtualize Unraid in Proxmox?”

No, at least not now.

Why this advice keeps coming up:

• People coming from enterprise or ZFS worlds

• People who already understand hypervisors

• People optimizing for snapshot-heavy VM workloads

Why it’s not ideal for you:

• SATA/NVMe passthrough adds fragility

• Debugging disk issues gets harder, not easier

• You lose Unraid’s simplicity benefit

If something breaks, you now have to ask:

Is it Unraid? Proxmox? The passthrough? The host kernel?

That’s not a fun learning experience.

---

2. “Does Docker inside Unraid defeat isolation?”

This is a very common misconception.

Reality:

• Docker already provides process, filesystem, and network isolation

• 99% of homelab services do not need VM-level isolation

• Security risk is dominated by:

  • exposed ports

  • weak auth

  • bad reverse-proxy config

Unraid Docker isolation is more than sufficient for:

• Immich

• Paperless-ngx

• Jellyfin

• Arr stack

• AdGuard / Unbound

VMs ≠ automatically safer. portainer and dockers can run in a LXC on proxmox or another VM like debian,ubuntu, OMV...

---

3. “Second Unraid instance for Docker?”

You’re correct:

• ❌ Requires another license

• ❌ Adds complexity

• ❌ Solves a problem you don’t actually have

Not recommended.

---

4. “Single Debian VM for Docker?”

This only makes sense if:

• You already dislike Unraid’s Docker UI

• You want to manage everything via Compose/Git

• You’re comfortable debugging Linux networking

Otherwise, it’s strictly harder than native Unraid Docker.

You also lose:

• Automatic appdata mapping

• Community App templates

• Simple backup tooling

---

5. “Multiple VMs/LXCs per service?”

This is enterprise thinking applied too early.

Trade-offs:

• ✔ Clean blast-radius boundaries

• ❌ Disk sprawl

• ❌ Backup complexity

• ❌ RAM overhead

• ❌ Management fatigue

For homelab services that mostly:

• talk over HTTP

• read/write files

• sit idle 90% of the time

…it’s unnecessary.

---

How Unraid actually manages hardware (simplified)

This is important for peace of mind:

• Disks

  • Each HDD is an independent filesystem

  • Parity is computed at the block level

  • No RAID rebuild storms

• Cache (NVMe)

  • Btrfs RAID1 → redundancy for appdata/VMs

• Docker

  • OverlayFS on cache

  • Direct host access (no nested virtualization)

• VMs

  • KVM, optional IOMMU

  • Only needed for Windows / special cases

You don’t have to think about “who owns the hardware” like in Proxmox.

---

About NVMe boot support

“Should I wait for Unraid NVMe boot?”

No. Don’t wait.

• USB boot is stable and proven

• The boot device is barely touched after startup

• Migrating later will be trivial

This shouldn’t block you from learning today.

---

A clean, beginner-proof recommendation

Phase 1 — Start here (weeks to months)

• Bare-metal Unraid

• HDD array + NVMe cache (RAID1)

• Docker via Community Apps

• Maybe one VM if you truly need it

Learn:

• Shares

• Cache behavior

• Docker networking

• Backups

Phase 2 — Optional evolution

If later you think:

“I want more control / reproducibility / GitOps”

Then:

• Add a Debian VM

• Or migrate to Proxmox with confidence

At that point, you’ll know why you’re doing it.

---

Final take

You’re not making things too simple—you’re accidentally making them too complex too early.

Unraid’s biggest strength is that it lets you:

run real services now, while learning gradually

That’s exactly what you want as a first homelab.

If you want, next we can:

• design a disk/cache/share layout

• map which services belong where

• or plan a future Proxmox migration path without locking you in

You’re on the right track 👍

9 hours ago, bmartino1 said:

For a beginner with your hardware and goals: run Unraid bare-metal first.
Skip Proxmox-for-now. You’re not missing out on anything critical, and you’ll learn much faster with fewer moving parts.

Model A — Unraid as the platform (recommended for you)

• Unraid is the OS

• Storage, Docker, light VMs all live together

• You get:

  • Disk spin-down

  • Dead-simple Docker UX

  • Community Apps (huge win for beginners)

  • Minimal hardware abstraction to understand

Model B — Proxmox as the platform

• Proxmox controls everything

• Unraid becomes “just another VM”

• You must understand:

  • PCIe passthrough

  • IOMMU groups

  • Storage layers (ZFS/LVM → VM disk → filesystem)

  • Backup strategies across hypervisor boundaries

This model is powerful, but it’s not beginner-friendly, and it does not actually reduce risk early on.

---

Your hardware is already perfect for Unraid

You’ve got an ideal Unraid box:

• i5-12600K → plenty of cores for Docker + Plex/Jellyfin transcoding

• 64 GB RAM → massive headroom

• Large HDD array → Unraid parity model shines here

• Multiple NVMe drives → perfect cache/appdata layout

Unraid’s value proposition (mixed disks + spin-down) is weakened when virtualized.

---

Q/A

1. “Should I virtualize Unraid in Proxmox?”

No, at least not now.

Why this advice keeps coming up:

• People coming from enterprise or ZFS worlds

• People who already understand hypervisors

• People optimizing for snapshot-heavy VM workloads

Why it’s not ideal for you:

• SATA/NVMe passthrough adds fragility

• Debugging disk issues gets harder, not easier

• You lose Unraid’s simplicity benefit

If something breaks, you now have to ask:

That’s not a fun learning experience.

---

2. “Does Docker inside Unraid defeat isolation?”

This is a very common misconception.

Reality:

• Docker already provides process, filesystem, and network isolation

• 99% of homelab services do not need VM-level isolation

• Security risk is dominated by:

  • exposed ports

  • weak auth

  • bad reverse-proxy config

Unraid Docker isolation is more than sufficient for:

• Immich

• Paperless-ngx

• Jellyfin

• Arr stack

• AdGuard / Unbound

VMs ≠ automatically safer. portainer and dockers can run in a LXC on proxmox or another VM like debian,ubuntu, OMV...

---

3. “Second Unraid instance for Docker?”

You’re correct:

• ❌ Requires another license

• ❌ Adds complexity

• ❌ Solves a problem you don’t actually have

Not recommended.

---

4. “Single Debian VM for Docker?”

This only makes sense if:

• You already dislike Unraid’s Docker UI

• You want to manage everything via Compose/Git

• You’re comfortable debugging Linux networking

Otherwise, it’s strictly harder than native Unraid Docker.

You also lose:

• Automatic appdata mapping

• Community App templates

• Simple backup tooling

---

5. “Multiple VMs/LXCs per service?”

This is enterprise thinking applied too early.

Trade-offs:

• ✔ Clean blast-radius boundaries

• ❌ Disk sprawl

• ❌ Backup complexity

• ❌ RAM overhead

• ❌ Management fatigue

For homelab services that mostly:

• talk over HTTP

• read/write files

• sit idle 90% of the time

…it’s unnecessary.

---

How Unraid actually manages hardware (simplified)

This is important for peace of mind:

• Disks

  • Each HDD is an independent filesystem

  • Parity is computed at the block level

  • No RAID rebuild storms

• Cache (NVMe)

  • Btrfs RAID1 → redundancy for appdata/VMs

• Docker

  • OverlayFS on cache

  • Direct host access (no nested virtualization)

• VMs

  • KVM, optional IOMMU

  • Only needed for Windows / special cases

You don’t have to think about “who owns the hardware” like in Proxmox.

---

About NVMe boot support

No. Don’t wait.

• USB boot is stable and proven

• The boot device is barely touched after startup

• Migrating later will be trivial

This shouldn’t block you from learning today.

---

A clean, beginner-proof recommendation

Phase 1 — Start here (weeks to months)

• Bare-metal Unraid

• HDD array + NVMe cache (RAID1)

• Docker via Community Apps

• Maybe one VM if you truly need it

Learn:

• Shares

• Cache behavior

• Docker networking

• Backups

Phase 2 — Optional evolution

If later you think:

Then:

• Add a Debian VM

• Or migrate to Proxmox with confidence

At that point, you’ll know why you’re doing it.

---

Final take

You’re not making things too simple—you’re accidentally making them too complex too early.

Unraid’s biggest strength is that it lets you:

That’s exactly what you want as a first homelab.

If you want, next we can:

• design a disk/cache/share layout

• map which services belong where

• or plan a future Proxmox migration path without locking you in

You’re on the right track 👍

First of all, I want to thank you for such a detailed answer; I think things are much clearer now.

I believe you're right, I was looking too much into things that don't offer any real utility at the moment, creating new issues along the way.
I think I'll stick to bare-metal Unraid for now. I assume the best practice would be setting the HDD array to XFS; however, I noticed you mentioned using Btrfs in RAID1 for the cache. I thought ZFS was now supported and the recommended filesystem for the NVMe pool. What would be the reason for choosing Btrfs instead?

In addition, since I’ll have three NVMe drives, I’m trying to determine the best way to distribute them. I was considering using the two Gen4x4 ports for the FireCuda and one SN850X so I can have redundancy through a mirror/RAID1 setup, while also mixing brands in case the WD batch has a defect. This pool would host my Docker containers and VMs, as well as the cache for important data like documents and Immich photos.

The other SN850X would go into the Gen4x2 port. What would be the best use for it? Since it won't have redundancy, I was thinking of using it as a "disposable" cache for things like movies, music, or a download scratchpad. Is there a better alternative? Could I keep, for example, recent films and the music I usually access there so I can increase the spin down time of the array? I could leave it as a spare, but it might be better to use it to reduce wear on the primary mirrored pair.

For now, I'll focus on getting everything running and understanding how services and Docker work. As you mentioned, I’ll need to design my disk and share layouts and decide how to configure everything. VLANs are probably something I need to take into account as well, so I’ll look into how Docker interacts with them.

Again, thank you so much for your time!

Edited January 24Jan 24 by EddieDS
Correcting mistake

What would be the reason for choosing Btrfs instead?

It's what unraid ships with the default array with parody

You didn't really share your disk layout setup, so I couldn't really go over a recommended unraid path of disks.

Yes, you can ditch the arrange highly and not use the default xfs or btrfs for pools.

I actually recommend raid Z1 with three disks of the same size.

Zfs also adds additional overhead and needs additional plugins and some side setup to get going

Review:

File systems | Unraid Docs

Selecting a file system type

Btrfs is default unRAID settings. Zfs is fine

https://docs.unraid.net/category/zfs/

3 nvme in a raidz1 should be fine for your needs

3 hours ago, bmartino1 said:

What would be the reason for choosing Btrfs instead?

It's what unraid ships with the default array with parody

You didn't really share your disk layout setup, so I couldn't really go over a recommended unraid path of disks.

Yes, you can ditch the arrange highly and not use the default xfs or btrfs for pools.

I actually recommend raid Z1 with three disks of the same size.

Zfs also adds additional overhead and needs additional plugins and some side setup to get going

Review:

File systems | Unraid Docs

Selecting a file system type

Btrfs is default unRAID settings. Zfs is fine

https://docs.unraid.net/category/zfs/

3 nvme in a raidz1 should be fine for your needs

I’ve reviewed everything you sent, and I’ve decided to go with XFS for the four HDDs (one for parity) and keep the NVMes in ZFS. However, after reading the documentation, I have a question regarding the pool configuration.

I noticed that RAIDZ1 is described as being fast for large files but less ideal for small, random writes. If I’m keeping my Docker containers and VMs inside that pool, wouldn't that be an issue? I’m concerned about potential latency since parity must be calculated in real time. From what I’ve gathered, a Mirror might be more suitable for this kind of random I/O workload.

Additionally, wouldn't a RAIDZ1 array be limited by the speed of the drive in the Gen4x2 port? I realize this is still far beyond the needs of a domestic network, but I’m curious if it could affect internal operations or system responsiveness.

Because of this, I’m still considering the approach I mentioned before: a two-drive mirror for my primary pool and a second "scratch" pool without redundancy for replaceable data, such as downloads from the Arr stack. Does that approach make sense, or am I missing something? Any relevant issue with this approach? Some benefit I might be missing from RAIDZ1?

I also noticed that compression is highly recommended; I would have completely overlooked it otherwise! I’ll also take note of the utilities and scripts you suggested.

Thank you so much!

Correct in theory and on paper, yes there is a performance hit. I manage multiple systems between some friends ins a ring network using unfi equipment and unifi's "teleport" / free site to site(one person owns the unfi router...)... A WireGuard vpn to rsync data between each other using the sftp docker, filezilla and user scripts. More, Plex media libraries, disk rips. Important data between each other.

We have been running unriad for the past 10 years(all of v6 and v7) and moved to zfs when possible(having tested truenas core, scale, omv, 45drives, etc...)we settled on unraid as it just works and has a nice Docker UI for easy access to console, log, control and maintain... (That said enterprise/commercial may have you look at Kubernetes, helm, portainer... dockers orchestrators) Unriad is OG dockerman and per research that is now under the podman docs.... BUT, I personally haven't seen issues with "Iops" i/o and latency with database and small files with read and writes. That said small files do happen and can cause more disk thrashing and is there more a mention as different hardware, silicone lottery and other user experiences can vary.

So
RAIDZ1 is described as being fast for large files but less ideal for small, random writes. If I’m keeping my Docker containers and VMs inside that pool, wouldn't that be an issue? I’m concerned about potential latency since parity must be calculated in real time.

Yes, it can. this is where monitoring and when you would add a special vdev to zfs such as l2arc to assist and help performance. That said we are talking enterprise level to see a impact. Something that sits idle won't really see this. Also unriad array is more famous for when things are idle and not active. Something like a database, monitoring or 24.7 plex will keep a disk spun up. zfs loses the power saving power draw that you would see in a traditional disk 1, disk 2 parity with the traditional unraid array setup.
most form reviewing the docs:
https://docs.unraid.net/

I have recently separated(refactored) my proxmox all in one (due to issues with aging software and hardware) with a bare metal to run plex, arrs on its own bare metal system. To assitn in separating our large plex libraries.... Using Iptv, plex, arrs to help monitor content I have legal access too and can acquire. this was more a recent hardware refactor of what i want running what and how to interact with it. More due to how my work vpn behaves and that I use for the plex and ars system...

That said I attempt to help where I can having messed with things Example For immich:
A decent photo backups, phones etc. see guides:
https://bmartino1.weebly.com/immich-on-unraid-ca-docker.html

I recommend learning docker compose and using that. But CA is a good place to begin and use unriads interface.
Especial when trying to learn and understand docker networks and how dockers communicate with each other:
https://bmartino1.weebly.com/guide-dockernetworks.html
https://www.youtube.com/watch?v=bKFMS5C4CG0

that said I do have a guide to use immich via compose.
https://bmartino1.weebly.com/immich-on-unraid-docker-compose-guide.html

for ars stack.
some other areas on the forum for ars:
https://forums.unraid.net/topic/194371-best-practice-for-arr-folder-structure/
also some compose setup to run ars:
https://forums.unraid.net/topic/196170-vpn-struggles-radarr-and-sonarr-unable-to-connect-to-sabnzbd-when-routing-through-vpn/#findComment-1598946
However the standalone apps also exist in the app store CA for unraid. Where you can slowly install run and follow a unriad template and there support pages for the docker in and of itself.

Pro cons to running dockers via compose, the unraid temples (default unraid standard) and how other distros run dockers. I recommend running compose as if there something you find you want to run on github 9/10 there's a compose file and its not hard to adapt and run that on unraid. (add additional labeling to use the unraid webui in conjunction...)

Sorry tangents and rants... Regarding storage:

Because of this, I’m still considering the approach I mentioned before: a two-drive mirror for my primary pool and a second "scratch" pool without redundancy for replaceable data, such as downloads from the Arr stack. Does that approach make sense, or am I missing something? Any relevant issue with this approach? Some benefit I might be missing from RAIDZ1?

that makes sense as it what you want it to do and how you want to interact with it. Disk have a MTF (mean time to failure) so it also about planning for how to recover and what you want to do to recover for when this happens.

For this reason I recomend a min of 3 disk as a raidz1 or a min of 5 disk in a raid z2 1 vdev.
as its easey to replace 1 disk keep everything and simple reslvier to keep data with zfs.

where and while possble I can be up with inserting a sinlge disk with zfs compared to moving editing and setup up the parity disk to restor a bad disk in the array. How I want to interact with it for recovery.
https://www.youtube.com/watch?v=qaP2tNk6QWA

https://www.youtube.com/watch?v=4B8J7VERBJY

https://youtu.be/EHbJKErI6HQ?si=H2WHaRGLu4D0cpMs

Space invader has quite a bit of youtube video going over things as well.

Hardware Recap

• HDDs: 4 × 24 TB WD White Label

• NVMEs:

  • 2 × 2 TB WD Black SN850X

  • 1 × 2 TB Seagate FireCuda (optional)

---

Option A (Recommended): ZFS Everywhere (No Unraid Parity)

This is the most technically clean ZFS setup and avoids parity-on-parity weirdness.

HDD Pool (Bulk Storage)

Pool: tank_hdd
VDEV: RAIDZ1

4 × 24TB  → RAIDZ1
Usable ≈ ~65–70 TB

Why RAIDZ1 here?

• Single-disk fault tolerance (equivalent to Unraid parity)

• Much better read performance than Unraid array

• Full ZFS checksumming + scrubs (silent corruption protection)

⚠️ RAIDZ2 would be safer but costs two disks — not worth it at 4 drives unless this is irreplaceable data.

---

NVMe Pool (Fast Data / Apps)

Pool: tank_nvme
VDEV: Mirror

2 × 2TB SN850X → MirrorUsable = 2TB

Use this pool for:

• Docker appdata

• VMs

• Databases

• Immich, Plex metadata, HA, Frigate, etc.

This gives:

• Redundancy

• Insane IOPS

• Low latency

---

Optional Third NVMe (FireCuda)

You have three good choices:

🔹 Option 1: ZFS Special Metadata VDEV (Advanced)

Attach FireCuda as SPECIAL vdev to tank_hdd:

• Stores metadata + small blocks

• Dramatically improves HDD pool performance

⚠️ Risk:

• If this disk dies → entire pool dies

• Only do this if you accept risk or mirror it later

🔹 Option 2: Dedicated Cache / Scratch Pool

Single-disk ZFS pool:

tank_scratch (FireCuda)

Use for:

• Transcodes

• Downloads

• Temporary data

• Non-critical workloads

🔹 Option 3: Don’t Use It

Perfectly valid. Less complexity, fewer footguns.

---

Option B: Hybrid (Unraid Parity + ZFS NVMe)

If you really want Unraid parity/spindown:

HDDs (Unraid Array)

• 1 × 24TB parity

• 3 × 24TB data

Pros:

• Disk spindown

• Simpler recovery model

Cons:

• No ZFS checksums

• Slower rebuilds

• Worse performance(in testing)

NVMe Pool (ZFS Mirror)

Same as above:

2 × 2TB SN850X → ZFS mirror

This is fine — just know the HDD array is the weak link.

---

Dataset Layout (Important)

Create datasets instead of dumping everything into the pool root.

HDD Pool (tank_hdd)

/media
/photos
/backups
/archives

Suggested settings:

• compression=lz4 (always)

• recordsize=1M for media

• atime=off

NVMe Pool (tank_nvme)

/appdata
/vms
/databases
/frigate
/immich

Suggested settings:

• recordsize=16K–128K

• sync=standard

• atime=off

---

Snapshot Strategy (Do This)

• Hourly snapshots (24h)

• Daily snapshots (30 days)

• Weekly snapshots (3–6 months)

ZFS snapshots are cheap — use them aggressively.

---

Scrubs & SMART

• Scrub: monthly

• SMART extended test: quarterly (stagger drives)
  
  

It more about is the disk in the array as disk 1, disk 2 parity or a group of # disk a pool device.
then what you want where.

On 1/24/2026 at 7:36 PM, bmartino1 said:

Correct in theory and on paper, yes there is a performance hit. I manage multiple systems between some friends ins a ring network using unfi equipment and unifi's "teleport" / free site to site(one person owns the unfi router...)... A WireGuard vpn to rsync data between each other using the sftp docker, filezilla and user scripts. More, Plex media libraries, disk rips. Important data between each other.

We have been running unriad for the past 10 years(all of v6 and v7) and moved to zfs when possible(having tested truenas core, scale, omv, 45drives, etc...)we settled on unraid as it just works and has a nice Docker UI for easy access to console, log, control and maintain... (That said enterprise/commercial may have you look at Kubernetes, helm, portainer... dockers orchestrators) Unriad is OG dockerman and per research that is now under the podman docs.... BUT, I personally haven't seen issues with "Iops" i/o and latency with database and small files with read and writes. That said small files do happen and can cause more disk thrashing and is there more a mention as different hardware, silicone lottery and other user experiences can vary.

So
RAIDZ1 is described as being fast for large files but less ideal for small, random writes. If I’m keeping my Docker containers and VMs inside that pool, wouldn't that be an issue? I’m concerned about potential latency since parity must be calculated in real time.

Yes, it can. this is where monitoring and when you would add a special vdev to zfs such as l2arc to assist and help performance. That said we are talking enterprise level to see a impact. Something that sits idle won't really see this. Also unriad array is more famous for when things are idle and not active. Something like a database, monitoring or 24.7 plex will keep a disk spun up. zfs loses the power saving power draw that you would see in a traditional disk 1, disk 2 parity with the traditional unraid array setup.
most form reviewing the docs:
https://docs.unraid.net/

I have recently separated(refactored) my proxmox all in one (due to issues with aging software and hardware) with a bare metal to run plex, arrs on its own bare metal system. To assitn in separating our large plex libraries.... Using Iptv, plex, arrs to help monitor content I have legal access too and can acquire. this was more a recent hardware refactor of what i want running what and how to interact with it. More due to how my work vpn behaves and that I use for the plex and ars system...

That said I attempt to help where I can having messed with things Example For immich:
A decent photo backups, phones etc. see guides:
https://bmartino1.weebly.com/immich-on-unraid-ca-docker.html

I recommend learning docker compose and using that. But CA is a good place to begin and use unriads interface.
Especial when trying to learn and understand docker networks and how dockers communicate with each other:
https://bmartino1.weebly.com/guide-dockernetworks.html
https://www.youtube.com/watch?v=bKFMS5C4CG0

that said I do have a guide to use immich via compose.
https://bmartino1.weebly.com/immich-on-unraid-docker-compose-guide.html

for ars stack.
some other areas on the forum for ars:
https://forums.unraid.net/topic/194371-best-practice-for-arr-folder-structure/
also some compose setup to run ars:
https://forums.unraid.net/topic/196170-vpn-struggles-radarr-and-sonarr-unable-to-connect-to-sabnzbd-when-routing-through-vpn/#findComment-1598946
However the standalone apps also exist in the app store CA for unraid. Where you can slowly install run and follow a unriad template and there support pages for the docker in and of itself.

Pro cons to running dockers via compose, the unraid temples (default unraid standard) and how other distros run dockers. I recommend running compose as if there something you find you want to run on github 9/10 there's a compose file and its not hard to adapt and run that on unraid. (add additional labeling to use the unraid webui in conjunction...)

Sorry tangents and rants... Regarding storage:

that makes sense as it what you want it to do and how you want to interact with it. Disk have a MTF (mean time to failure) so it also about planning for how to recover and what you want to do to recover for when this happens.

For this reason I recomend a min of 3 disk as a raidz1 or a min of 5 disk in a raid z2 1 vdev.
as its easey to replace 1 disk keep everything and simple reslvier to keep data with zfs.

where and while possble I can be up with inserting a sinlge disk with zfs compared to moving editing and setup up the parity disk to restor a bad disk in the array. How I want to interact with it for recovery.
https://www.youtube.com/watch?v=qaP2tNk6QWA

https://www.youtube.com/watch?v=4B8J7VERBJY

https://youtu.be/EHbJKErI6HQ?si=H2WHaRGLu4D0cpMs

Space invader has quite a bit of youtube video going over things as well.

Hardware Recap

• HDDs: 4 × 24 TB WD White Label

• NVMEs:

  • 2 × 2 TB WD Black SN850X

  • 1 × 2 TB Seagate FireCuda (optional)

---

Option A (Recommended): ZFS Everywhere (No Unraid Parity)

This is the most technically clean ZFS setup and avoids parity-on-parity weirdness.

HDD Pool (Bulk Storage)

Pool: tank_hdd
VDEV: RAIDZ1

4 × 24TB  → RAIDZ1
Usable ≈ ~65–70 TB

Why RAIDZ1 here?

• Single-disk fault tolerance (equivalent to Unraid parity)

• Much better read performance than Unraid array

• Full ZFS checksumming + scrubs (silent corruption protection)

⚠️ RAIDZ2 would be safer but costs two disks — not worth it at 4 drives unless this is irreplaceable data.

---

NVMe Pool (Fast Data / Apps)

Pool: tank_nvme
VDEV: Mirror

2 × 2TB SN850X → MirrorUsable = 2TB

Use this pool for:

• Docker appdata

• VMs

• Databases

• Immich, Plex metadata, HA, Frigate, etc.

This gives:

• Redundancy

• Insane IOPS

• Low latency

---

Optional Third NVMe (FireCuda)

You have three good choices:

🔹 Option 1: ZFS Special Metadata VDEV (Advanced)

Attach FireCuda as SPECIAL vdev to tank_hdd:

• Stores metadata + small blocks

• Dramatically improves HDD pool performance

⚠️ Risk:

• If this disk dies → entire pool dies

• Only do this if you accept risk or mirror it later

🔹 Option 2: Dedicated Cache / Scratch Pool

Single-disk ZFS pool:

tank_scratch (FireCuda)

Use for:

• Transcodes

• Downloads

• Temporary data

• Non-critical workloads

🔹 Option 3: Don’t Use It

Perfectly valid. Less complexity, fewer footguns.

---

Option B: Hybrid (Unraid Parity + ZFS NVMe)

If you really want Unraid parity/spindown:

HDDs (Unraid Array)

• 1 × 24TB parity

• 3 × 24TB data

Pros:

• Disk spindown

• Simpler recovery model

Cons:

• No ZFS checksums

• Slower rebuilds

• Worse performance(in testing)

NVMe Pool (ZFS Mirror)

Same as above:

2 × 2TB SN850X → ZFS mirror

This is fine — just know the HDD array is the weak link.

---

Dataset Layout (Important)

Create datasets instead of dumping everything into the pool root.

HDD Pool (tank_hdd)

/media
/photos
/backups
/archives

Suggested settings:

• compression=lz4 (always)

• recordsize=1M for media

• atime=off

NVMe Pool (tank_nvme)

/appdata
/vms
/databases
/frigate
/immich

Suggested settings:

• recordsize=16K–128K

• sync=standard

• atime=off

---

Snapshot Strategy (Do This)

• Hourly snapshots (24h)

• Daily snapshots (30 days)

• Weekly snapshots (3–6 months)

ZFS snapshots are cheap — use them aggressively.

---

Scrubs & SMART

• Scrub: monthly

• SMART extended test: quarterly (stagger drives)
  
  

It more about is the disk in the array as disk 1, disk 2 parity or a group of # disk a pool device.
then what you want where.

I’ll definitely have to come back to the Docker tutorials once I have the arrays up and running. Some of the examples feature services I plan to use, so they will be very helpful.

I have one question regarding the "how to handle a failed drive" video: he preclears the disk once it's added to Unraid. I ran HDDScan’s "Erase" on all my disks before shucking them, and they all came back without any bad sectors. Should I repeat the process in Unraid for any particular reason?

Regarding disk formatting: I hadn’t considered using ZFS for the HDD array. I understand the benefits of checksums and snapshots, but would I lose the ability to spin them down altogether? At the moment, the electricity cost of a few extra HDDs isn't a concern, nor is the noise though less is always better. However, I’m worried about unnecessary disk wear. Since I’m starting with high capacity, would it be possible to keep at least two of them spun down most of the time? What would be the best approach here? I might be overestimating the benefit of spinning down disks.

As for the increased performance, if I’m not mistaken, it would mainly affect read speeds since I’m using NVMe drives for cache. In what cases could this be a limitation for general use?

I’m definitely skipping the Metadata VDEV; adding a single point of failure doesn't seem like a good idea. I think I’ll go for the mirrored ZFS pool. I noticed you recommended mixing both SN850X drives], isn’t it better practice to mix brands? Since both SN850X drives were manufactured on the same day, couldn’t they potentially share a manufacturing defect? I’ll decide whether to keep the third NVMe as a spare or use it as a scratch pool to reduce wear on the mirror.

I always try to keep everything organized in folders. I assume datasets also allow for personalizing which services can access specific data?

Thanks again for the detailed answer; it’s been very instructive!

Pre-Clear is optional. Essentially that just writes all zeros to the disk which is not necessarily needed in recovery and repair. can it help sometimes. its better to let unraid rebuild format and do what its needed to do. what the point of 0 out a disk if unraid has to do that again anyway. can it speed up the process in recovery sometimes in a traditional array xfs, btrfs setup. the zfs hybrid makes a zfs disk 1 share with a single disk and the hybrid approach gets complicated with zfs pool to maintain the unraid parity and array workings. With ZFS its best to use # of disk and grouping of disk in a mirror, raidz1, raidz2 and other to set # of disk, type of disk and in a set for zfs to use. Raidz1 is the golden standard of 3 disk. Mirrored and striped lose 1 disk keep the data. raidz2 needs a min of 5 disk lose 3 disk keep the data...

There are other videos, documentation that one would direct and use that was more an example of the unraid web UI and how someone would handle and mange a disk replacement. Each situation can be unique flowing guidance docs and steps in your backup to recovery is what works best here. a backup is only as good as you are able to recover. with zfs it removes the bad disk (some commands can be ready before) in main drop down and select the new disk and zfs will run a resilver and a scrub to rebuild that disk from parity. (ideal with systems like dockers, and share down until the resilver is done.)

https://www.reddit.com/r/zfs/comments/sfo1tq/linus_tech_tips_fails_at_using_zfs_properly_loses/

 

https://youtu.be/Npu7jkJk5nM?si=Z_Ln8T6h_ElEq3V7

 

This said, ZFS doesn't necessarily mean spin down doesn't work. but if you have constant read and writes to the array, spin down won't work regardless. I also tend to avoid spin down and build 24/7 based machines. a old habit form building stuff for government agencies, healthcare things that need min downtime for a day. if you constantly play plex on a zfs disk of pools, the disk will never go down, if a docker is writing its database even when idle to a disk same, it will never spin down... this is where nvme for dockers shine due to the speed and interaction.

Spin down... That's more dependent on how you're handling shares. How often active files just need to be used for storage.

Since using the nvme drive for cache, it's more on how you handle shares and mover when we put files between cash and the array of the pool. Limitations are there based on file access, speed of data you'd written and where the file is actually located based on what we call the disk share.

General practice yes you mix dries are the same size, but when you mix brands, not all brands share the same size for a single terabyte as an example.

The nvme is not a full terabyte. Compared to a terabyte on SSD compared to a terabyte on a HDD. And when the bites don't match that becomes problematic. In the past it was best to mix and match drives due to how raid array worked and what raid array versions you are using to be able to handle the storage with Parity.

Zfs raidz1 you one is akin to raid 5/6

And yes, this is where data sets become important as each data set can be set up and created with different options and availability as if it was its own file system.

Things such as no atime, compression, deduplication... more info on that in another systems... (depending on someone's turenas build yes the disk can be imported into unraid...)

 

https://youtu.be/0d4_nvdZdOc?si=mBxSp9sHKdzPIaq1

 

https://www.youtube.com/watch?v=oNQ3UuRROoc

unraid uses openzfs:
https://openzfs.org/wiki/Main_Page

So…
Example /tank/media

In the end a dataset does become a folder path, that’s a regular folder(media) at the base of the pool (tank) and you can make datasets of subfolders...

But unraid will only see the base folder at the very beginning for shares.

zfs pool of 3 disks raidz1 lets call it tank. zfs will root map the disk to /tank on distros. in unraid tank can be found at /mnt/tank
we can make a dataset called media

And another dataset in a dataset /tank/media/sub-dataset (via zfs create commands or zfs master plugin)

or use the media dataset i.e. mkdir /tank/media/folder

When you make the original share data set of tank/media.

This will be seen in the unraid under the share tab and will be added to the samba config and NFS config if you enable it for sharing. (sometimes you have to fix unraids share settings of primary disk...

At creation of tank/media, you can specify and use specific ZFS commands in the terminal or via the ZFS master plug-in and set things such as encryption, compression, deduplication case, sensitivity, and other things that you may or may not want based on the nature of the data that will be added to this data set.

Unraid only handles the base Main dataset. so ideally while one can have subdatasets its recommend to plan for pool/dataset/folders_and_data

As you can create a sub data set within a main data set. but that can cause issues As you created a sub data set within a main data set. An unraid will not be able to manipulate or use this with the shares via the web ui...(thats what i have found in testing

And a data set is different compared to the folder. form snapshots and access. As the folder is data within the data set which will be then handled by the snapshot.

So ideally you would make a data set for backups that would have compression and deduplication.

For media because of the high volume of movies and picture files, you may not want compression, but you may want other a ZFS options.

Depending on other share folders so those pictures samba cloud. Whatever you call your folder structure moving forward.

This is especially important when we get to docker's folder structure on where data is being stored and how the docker is interacting from the containered version to the host unraid.

A good example is the ars setup:

https://trash-guides.info/File-and-Folder-Structure/

Unraid uses what's called a fuse system

https://www.youtube.com/watch?v=xec1DHpmztM

So even though the pool is tank/media

Unraid will have a fuse structure located at /mnt/user/media

This is akin to Sim Link and shortcuts.

And you would most likely want to interact with all the data at Mount user.

Unless you want a disk share and you want it directly on the pool then you want to mount it at tank/media.

Is very important to have set up a folder hierarchy structure, especially when you have multiple disks. Of what data is expected to be stored? Where.

And your case because of the single cash disk.

I would expect Docker data such as app data. The configurations that run dockers be stored on the nvme drives.

And large storage files such as media pictures that would run from the dockers be stored on the separate pools such as the SDDs or the hdds.

And those pools are then used for short-term access, deep storage and other various aspects to maintain your data.

Raid is not a backup. It is redundancy and house. Keep up time.

This is also where we go into the 321 rule.

Important data needs to be stored on three disks at two separate locations with one off-site location.

This is the guarantee file recovery, backup and access to a file.

The 221 is also acceptable. Two discs two locations one off site.

And this is where the nvme disk drive or single pool may not be best practice but functions just the same.

Rated acts as more as a mirror in these aspects. So if a disk fails, you still have the data. The machine can still be on and function but it's degraded until you replace the disk or update the disk for storage.

 

Edited January 27Jan 27 by bmartino1
Cloudflare outage yesterday mobile post broken data

Preclear vs what you already did

Preclear in Unraid is optional, not mandatory.

You already ran a full erase + surface scan with HDDScan and confirmed no bad sectors. From a data-integrity standpoint, that accomplishes the same goal: verifying the disk is healthy before putting it into service.

Historically, Unraid preclear mattered more because:

• It allowed adding a disk to an existing parity-protected array without taking the array offline

• It stress-tested new disks to catch early failures

If you’re:

• Building the array fresh, or

• Using ZFS (which will rewrite metadata anyway)

…there’s no strong reason to repeat a preclear. Unraid/ZFS will write what it needs during formatting, resilvering, or pool creation regardless. In short: you’re fine skipping it.

---

ZFS on HDDs and disk spin-down

ZFS does not inherently prevent spin-down, but in practice it greatly reduces how often disks can sleep.

Reasons:

• ZFS periodically touches metadata

• Scrubs, ARC metadata updates, and dataset activity keep disks “warm”

• Any active dataset keeps its entire vdev active

So while spin-down can technically work, ZFS is best thought of as a 24/7 system.

That said:

• Disk wear from spinning is generally less harmful than frequent spin-up/down cycles

• Modern enterprise-grade HDDs are designed for continuous operation

If power/noise aren’t major concerns (as you said), I would not over-optimize for spin-down. You’re likely overestimating its benefit.

Important limitation:
With ZFS, you cannot selectively spin down “two of four disks” in the same vdev. If any dataset in a vdev is accessed, all disks in that vdev stay active. Selective spin-down only really works with Unraid’s traditional per-disk array model.

---

Performance considerations (with NVMe cache)

You’re correct: most performance gains from ZFS on HDDs show up in read performance, metadata operations, and integrity guarantees — not raw write speed.

Since:

• Docker + appdata live on NVMe

• Writes land on cache first

The main cases where HDD ZFS performance matters are:

• Large sequential reads (media scanning, backups)

• Scrubs/resilvering

• Direct reads from the HDD pool (bypassing cache)

For general home-server usage, this is rarely a bottleneck.

---

ZFS layout sanity check

You’re absolutely right to skip a single-disk metadata/special vdev — that is a single point of failure unless mirrored.

Good choices:

• Mirror (simple, fast resilver, predictable)

• RAIDZ1 (minimum 3 disks, space-efficient)

• RAIDZ2 only makes sense at larger disk counts

ZFS works best when disks are:

• Same size

• Same role

• Grouped intentionally (mirror vs RAIDZ)

Trying to “hybridize” ZFS with Unraid’s parity array model gets complicated fast and usually isn’t worth it.

---

NVMe mirror & “same batch” concern

You’re asking the right question here.

Yes, in theory, drives from the same batch could share a latent defect. In practice:

• Modern SSD failure modes are far less batch-correlated than HDDs

• Power events, firmware bugs, and wear patterns dominate failure causes

Mixing brands can help diversity, but it also introduces:

• Firmware behavior differences

• Performance asymmetry

• Slight capacity mismatches

For NVMe mirrors:

• Same model is perfectly acceptable

• Keeping the third NVMe as a spare or scratch pool is a solid plan

If you’re extra cautious, a different model is nice — but not required.

---

Datasets vs folders (important distinction)

Yes — datasets are exactly how you control behavior, access, and policy.

Key points:

• A dataset ≠ folder

• Datasets get their own properties: compression, encryption, snapshots, ACLs

• Folders inside a dataset inherit its behavior

In Unraid specifically:

• Unraid only manages the top-level dataset as a share

• Sub-datasets exist, but Unraid’s UI won’t manage them cleanly

Best practice in Unraid:

pool
└── dataset (Unraid share)
    ├── folders (media, backups, photos, etc.)

Avoid creating sub-datasets inside a dataset that Unraid already manages — that’s where UI confusion starts.

Docker/appdata should absolutely live on NVMe datasets; bulk media belongs on HDD pools.

---

Final reminder (you nailed this already)

RAID/ZFS ≠ backup.

Follow:

• 3-2-1 if the data matters

• At least 2-2-1 if you’re constrained

ZFS gives integrity and uptime — not immunity.

On 1/26/2026 at 6:18 PM, bmartino1 said:

Preclear vs what you already did

Preclear in Unraid is optional, not mandatory.

You already ran a full erase + surface scan with HDDScan and confirmed no bad sectors. From a data-integrity standpoint, that accomplishes the same goal: verifying the disk is healthy before putting it into service.

Historically, Unraid preclear mattered more because:

• It allowed adding a disk to an existing parity-protected array without taking the array offline

• It stress-tested new disks to catch early failures

If you’re:

• Building the array fresh, or

• Using ZFS (which will rewrite metadata anyway)

…there’s no strong reason to repeat a preclear. Unraid/ZFS will write what it needs during formatting, resilvering, or pool creation regardless. In short: you’re fine skipping it.

---

ZFS on HDDs and disk spin-down

ZFS does not inherently prevent spin-down, but in practice it greatly reduces how often disks can sleep.

Reasons:

• ZFS periodically touches metadata

• Scrubs, ARC metadata updates, and dataset activity keep disks “warm”

• Any active dataset keeps its entire vdev active

So while spin-down can technically work, ZFS is best thought of as a 24/7 system.

That said:

• Disk wear from spinning is generally less harmful than frequent spin-up/down cycles

• Modern enterprise-grade HDDs are designed for continuous operation

If power/noise aren’t major concerns (as you said), I would not over-optimize for spin-down. You’re likely overestimating its benefit.

Important limitation:
With ZFS, you cannot selectively spin down “two of four disks” in the same vdev. If any dataset in a vdev is accessed, all disks in that vdev stay active. Selective spin-down only really works with Unraid’s traditional per-disk array model.

---

Performance considerations (with NVMe cache)

You’re correct: most performance gains from ZFS on HDDs show up in read performance, metadata operations, and integrity guarantees — not raw write speed.

Since:

• Docker + appdata live on NVMe

• Writes land on cache first

The main cases where HDD ZFS performance matters are:

• Large sequential reads (media scanning, backups)

• Scrubs/resilvering

• Direct reads from the HDD pool (bypassing cache)

For general home-server usage, this is rarely a bottleneck.

---

ZFS layout sanity check

You’re absolutely right to skip a single-disk metadata/special vdev — that is a single point of failure unless mirrored.

Good choices:

• Mirror (simple, fast resilver, predictable)

• RAIDZ1 (minimum 3 disks, space-efficient)

• RAIDZ2 only makes sense at larger disk counts

ZFS works best when disks are:

• Same size

• Same role

• Grouped intentionally (mirror vs RAIDZ)

Trying to “hybridize” ZFS with Unraid’s parity array model gets complicated fast and usually isn’t worth it.

---

NVMe mirror & “same batch” concern

You’re asking the right question here.

Yes, in theory, drives from the same batch could share a latent defect. In practice:

• Modern SSD failure modes are far less batch-correlated than HDDs

• Power events, firmware bugs, and wear patterns dominate failure causes

Mixing brands can help diversity, but it also introduces:

• Firmware behavior differences

• Performance asymmetry

• Slight capacity mismatches

For NVMe mirrors:

• Same model is perfectly acceptable

• Keeping the third NVMe as a spare or scratch pool is a solid plan

If you’re extra cautious, a different model is nice — but not required.

---

Datasets vs folders (important distinction)

Yes — datasets are exactly how you control behavior, access, and policy.

Key points:

• A dataset ≠ folder

• Datasets get their own properties: compression, encryption, snapshots, ACLs

• Folders inside a dataset inherit its behavior

In Unraid specifically:

• Unraid only manages the top-level dataset as a share

• Sub-datasets exist, but Unraid’s UI won’t manage them cleanly

Best practice in Unraid:

pool
└── dataset (Unraid share)
    ├── folders (media, backups, photos, etc.)

Avoid creating sub-datasets inside a dataset that Unraid already manages — that’s where UI confusion starts.

Docker/appdata should absolutely live on NVMe datasets; bulk media belongs on HDD pools.

---

Final reminder (you nailed this already)

RAID/ZFS ≠ backup.

Follow:

• 3-2-1 if the data matters

• At least 2-2-1 if you’re constrained

ZFS gives integrity and uptime — not immunity.

I’ve been looking into UniFi Teleport based on your previous answer. Since I already have a UniFi switch and gateway, it might be better for me to use it over Tailscale or a direct WireGuard connection to access the server on the go. Will think about it.

Got it, I can skip the pre-clear process if I’m using ZFS, and I assume the same applies to XFS.

Regarding disk wear, I’ve been researching whether spinning down is better for the drives and couldn't find a consensus. In the case of ZFS, it might be better to skip it altogether. As you mentioned, any access to a single disk in a ZFS pool would spin up the entire array. You mentioned that 24/7 spinning is better than frequent cycles, but what is considered "frequent"? I would save around 25€ a year with four disks, but that could rise to 75€ once I populate all available 12 bays.

I didn't realize that "batch mixing" was more of an HDD concern. Since the FireCuda has a higher TBW, it’s likely more suitable for a scratch cache. I’ll keep the two SN850X drives in the mirror.

I need to dig deeper into shares, but from what I gather, I should create a dataset for each type of data rather than using subfolders within a single dataset. Instead of a single "tank/media" dataset with "photos," "movies," and "music" subfolders, I should create three separate datasets: "tank/photos," "tank/movies," and "tank/music." This way, I can assign different options to each dataset and isolate which Docker services can access them.

I plan to follow the 3-2-1 backup rule for my important data. For movies and music, I’ll likely rely on redundancy alone. For photos and non-replaceable data, my plan is to keep one copy on the array, one on an external NVMe drive, and a third backed up to a cloud service. In the future, I might add two Barracudas from my main PC (that are not being used much) as a secondary array for local backups to replace the external NVMe.

Lastly, I’m a bit worried about future expansions with ZFS. If I understand correctly, increasing capacity would require me to add the exact same number of disks I already have. So, to expand my current 4-disk setup, would I need to add another 4x 24TB drives? If I want to max out the 12 bays, I would need to reado the array since I can't add another 8. Am I missing something here? Must the disks be the same model too? I know it’s possible to format disks in ZFS individually, but I assume I’d lose most of the advantages of ZFS that way. Seems like completely liking unRAIDs versatility going down this route.

Thanks again!

unifi teleport and tailscale use WireGuard underneath to make their connections ...

its a bit easier to set up and use unifi. Both sites usualy need unifi router/gateway for sit to site. otherwise unfi webman / teleport:

Some more info on unfi vpns and teleport
https://help.ui.com/hc/en-us/articles/360002426234-UniFi-Gateway-Site-to-Site-IPsec-VPN

unfi to unfi site to site. unfi to clients telport.
From an easy enterprise app/phone... use unifi site to site and let the routers handle the traffic then 3rd partys, or the linux hosts/dockers...
linuix host and other mangle where some are not meant to manage networking at all.
site to site works (even cgnat locations...) although atleast 1 location needs a public IP... they use unfi servers as a broker...


https://help.ui.com/hc/en-us/articles/5246403561495-UniFi-Gateway-Teleport-VPN
also common for windows client to connect similar linux clients can connect to teleport:
https://community.ui.com/questions/Teleport-and-VPN-on-Windows/853f7328-a88b-4824-806a-3c7840ac60ac

many vpn self-host solutions. but tis running wireguard stuff to accomplish what it does... unfi also can support self-host WireGuard setups as well...

you can have unraid WireGuard vpn connect to unfi as well:
https://www.reddit.com/r/unRAID/comments/1pavm3t/video_guide_wireguard_on_unraid_the_best_method/
https://www.youtube.com/watch?v=GEMrmXs10To

For disk recovery Correct same for xfs array. see https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/
*Got it, I can skip the pre-clear process if I’m using ZFS, and I assume the same applies to XFS.

Cool as I know there been a lot of info dump on things here.

Disk wear and other usually comes from the manufacture standards and material to make most disk have a MTF. Meantime to failure where they are stressed tested by the manufacture and hit xyz requirement for economic standards to follow and their own in hose to pass. A Lot of refirb disk go though a stress test after recycling of parts...

Things that carry and mark SMART for example, there also a universal standard that something should follow.. Like the (iso-2003 irerelvant) standard via international standard covering small to the manfactureing company manufacturing with nuts to be metric 13 or 1/4 sizes...

see:
https://nfina.com/white-papers/not-all-hard-drives-are-created-equal/

and since your using mostly segate disks:
https://www.seagate.com/support/kb/hard-disk-drive-reliability-and-mtbf-afr-174791en/

I usaly run exo enterprise based drives. I've bought them fairly cheap 10ish years ago and had very little to 0 isseus even with refirb...
example: https://harddiskdirect.com/st10000nm002g-1305535.html

then theirs the disk cache with CSM vs srm... You really want CSM disk...

https://www.youtube.com/watch?v=rC0UDtCiYgI

Usually its folloiwng what manufacture say, and 3rd party indpendant tests. Then local Laws that hold companies to their word...

AS disk even unraid make software raids. Unriads big selling point is the abilty to mix and match disk in a standard array xfs setup.
not to be confused when saying array with zfs raidz1 (they are different sharing the array word terminology...)

I agree, ask quesitons. Ill try to give you my sources ...

*I need to dig deeper into shares

All I can say is read the unraid docs and trial/error test for your self.
https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/shares/
as I can only go over things I have done why i ended up where I'm am now. and things that I have experienced. There are many forum posts as well with (mods and known people on teh forum)Jorge, Simon and others that go over this as well.

as theses are the question to ask your self to setup a folder hierarchy where do you want what saved and how are you access what where.

as it comes down to what you want it to do and how you want to interact with it.

Lastly, I’m a bit worried about future expansions with ZFS

Expansion can happen in a number of ways. 3 that I have tested and used...

My example 1:


I have 3 Seagate x16TB exo disks. ZFS uses the lowest disk to set and use as estimated size.

To increase space I can do a couple of things.
1 slowly replace each 16 TB disk with higher capacity disk... ie get 3 disks 18TB, 24TB, etc... (all 3 need to be at higher capacity)
after the 3rd 16 TB replacement disk it ZFS will increase space. if i grabbed a x18 and 2x 24 then I would lose the detail space form a 24 TB as they would drop to 18 TB and i would gain aprox 2-6 TB of additional space.
Then later when I get another 3rd 24 TB I would gain the additional 10TB...

OR. I can add a special DISK and make another vdev adding to the existing disk of pools. Adding another new vdev (as the existing 3 disk) or ad more disk and make a new pool. All on how you want to handle storage.
It comes down to what makes sense for your setup and data...

Otherwise, I have to have the disk in hand I make another pool and copy the data off the old as I can pull a disk use that as a main running degraded and build a new set of disk pools...

But yes, ZFS can and does lock in due to how it handles its raid machines... making expansion complex not impossible.

see:
https://www.reddit.com/r/zfs/comments/jayyuk/expanding_the_capacity_of_zfs_pool_drives/
Unriad is also still working on some of the zfs integrations ion the web ui most of these are terminal command line...

Truenas goes over expansion, zvol, zpool vdevs stuff a bit more and better. (trueans was also built on and used zfs first...) trueness zfs is their own prietartery privately works.. Thus others that use zfs use open zfs...

example:
https://www.youtube.com/watch?v=uPCrDmjWV_I

it can be done in unraid and as time goes on zfs has and will get these features for ease of access. Not all of zfs otpions, configuration exist in unraid yet.
review:
https://freebsdfoundation.org/blog/openzfs-raid-z-expansion-a-new-era-in-storage-flexibility/

example in my PVE: ( I let pve control and mange zfs and pass teh data vbpool into my unraid VM for data... unraid gets a qdisk for a single cahce disk taht is using my nvme vm zfs mirror.
*this way unard still has disk via QEMU shaniagins and done't touch the disk (as i'm short on borad pcie lanes to pass the disk into the vm to be seperate form the host so why not let the host mange and control the disk and let unriad interact with them akin to a samba share.



I have 2 disk in a mirror:


since both of theses disk are in a mirror I can't add a disk and change it to a zfs raidz1 its done at the beginning. so zfs expansion can be a bit tricky. Same in unraid once you set the pill # of disk you would have to delete the pool and its data to change form a mirro to a riadz1 to a raid z2

That said zfs, unraid and features to do this are in progress and incoming open zfs is working on new expansion stuff.
https://www.youtube.com/watch?v=tEBpfzVzNiY
OpenZFS does not support in-place conversion from a mirror to a RAIDZ1 vdev; the pool must be destroyed and recreated. To migrate, you must back up all data, destroy the mirror, create a new RAIDZ1 pool using all desired disks, and restore the data...

zfs has its own docs that i'm still parsing through.
https://openzfs.github.io/openzfs-docs/
zfs is a best in and of itself and is more enterprise grade targeted. There is nothing wrong with useing the traditional disk 1 disk 2 party 1 pairty 2
just know that prity 2 is for disk 2 and not hte whole array.

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/overview/

Removing disks from array | Unraid Docs

There may come a time when you want to remove a disk from your Unraid array. Whether you're looking to save on power, retire an old or unreliable drive, or repurpose hardware for a different use, the

This is why I said disk failure replament can be complicated and glossed over it earlier in posts... regardless of what setup you have. and a forum separate post should be made with the main pitcure, dig and other are here to help support adn give advise on how to correct and fix / replace to get you back up and running.

who knows, maybee unraid is not a good fit for your use cae. Many ways to acomplsh things. Unaid provdes a nice web ui and some CA frist cleick run and done. alot fo tinker can be done on any platform to acomplsh your needs.

So I ask you want is that you are wanting to do and I can give you other exampels and platfomrs..

sucah as everythign that unraid does I can manuly do ina debain linux terminal but then i'm stuck in termainl comand land and I dont' want to have to always interacte with a shell / ssh session or tty line... taht wehre other platfoprms come in such as portainer to mange dockers with a web ui wher otehr platfomrs suchas as webmin come in.. and even where unraid shine having a web ui control interface...

(even there webui can me simlar shaped for otehr sytems... Unriad runs slackware linux. slck is great but I prefe my debain repos and projhects 9its what i kow and have expereince with other via documentiaont and being a know relaibale stable...

this is where one may say open meda vualt or proxmox makes sense do to what you want it to do and how you wnat to ineteract with it. Als a common phase as we alos end up in circles where we "reinvent the wheel" and great you can do that on xyz but is it stable and do you really want to interace with it this way in this manner.

this is why i reocmen unriad first due to the docs, the forum, the support and is easy learning curve. can it get complex yes, are there advance thing to do ye, but make post, ask quiest and people here will try to help.