Hello all - building my 1st server. Mainly will be used for plex, but also some video editing, and maybe some VM in the future and/or who knows. Hardware:

 

12600k

z690 gigabyte aorus master

4 x 22TB HDD's

3 x 1TB M2's

128gb ram

2gb fiber optic

 

Thinking I want to do zfs pool of the HDD's mainly as I plan to allow several people to stream plex

Obviously want zfs as pools but with this setup, and UnRaid 7.0, my main question right now is should I create a single cache pool with raidz of the M2's, or use the new "sub pools" to create various pools (L2Arc, slog, special?), or both?. I've spent a lot of time scouring the net but haven't been able to find out. Welcome any insights and thanks.

review:

Depends on if you got beta 7 or 6 stable standard.
if 7 you can ditch the unraid array all together and go ZFS.

My recommendation ZFS:
4x 22TB raidz2
3x 1TB raidz1

 

Thank you friend. Yes I have the beta and have the HDD's in a zfs pool. The simple raidz1 cache pool is nice and easy. I didn't know if I should simply do that, or use the sub pool feature of the main zfs pool to create a l2arc cache, slog, special zfs pool or not. And/or if I should have larger/more nvme's to do it all proper.

I personlay wouldn't do sub pools on unraid yet. Unraid needs a little more polish in the Web UI for ZFS before I recommend that. They are starting to do better with vdevs on raidz2.

 

Notes:

L2ARC and SLOG require thoughtful tuning to see real benefits. By default, Unraid’s beta ZFS support might not optimize for these; you may need to tweak zfs parameters manually.

ZFS pools don’t have to match the size of your workload perfectly for caching, but over-provisioning cache for workloads that don’t need it can be wasteful.

Monitor performance and scale as needed—your hardware is future-proofed for significant upgrades.

*Its best to keep same type of nvme in a zfs pool this is to keep with same partition blocks and speed.
 

Your Setup Analysis

Main ZFS Pool (HDDs):

You already have a 4x 22TB HDD pool in RAID-Z2, which is an excellent choice for redundancy and resilience for a media server. RAID-Z2 provides two-disk fault tolerance, crucial for large capacity drives where rebuilds take significant time.

Cache Pool Options (NVMe):

The three 1TB NVMe drives are versatile. You could either use them for a simple RAID-Z1 cache pool or leverage ZFS-specific features like L2ARC, SLOG, or a special metadata pool.

 

Key Considerations

 

1. Cache Pool Design

RAID-Z1 Cache Pool:

This is straightforward, provides redundancy, and boosts write performance. This is an easy setup for caching frequently accessed data.

Sub-Pools with Specialized Roles:

L2ARC (Read Cache): Good for speeding up reads of frequently accessed files. Useful if your Plex server or VMs access the same data repeatedly.

SLOG (Write Cache): Useful if you enable synchronous writes, which some workloads (like VMs or video editing) might benefit from. However, unless your workload heavily depends on synchronous writes, this may not be necessary.

Special Metadata Pool: Great for indexing and metadata-heavy workloads, which can significantly boost filesystem traversal and Plex library scans.

 

2. Future Expandability

If you plan on scaling workloads (e.g., hosting more VMs or increasing Plex library size), you might consider adding more or larger NVMe drives to handle L2ARC/SLOG/special pools independently.

Recommendation for Your Setup

Main ZFS Pool:

Stick with your 4x 22TB RAID-Z2 for the HDDs. It balances redundancy and capacity well.

 

NVMe Cache:

If simplicity is key, use a RAID-Z1 configuration for all three NVMe drives as a single cache pool.

If you want to leverage ZFS's advanced features:

Dedicate 1 NVMe drive for a SLOG. Even though your 12600K may not fully stress ZFS synchronous writes, this ensures optimal VM and video editing performance.

Use 2 NVMe drives in a mirror configuration for a special metadata pool and L2ARC. This improves performance for Plex library scans and other metadata-intensive tasks.

Larger/More NVMes:

If you want the most out of ZFS, especially for VMs and heavy video editing workloads, consider adding at least one more NVMe for better separation of SLOG, L2ARC, and metadata pools.

 

 

 

Wow! That is great and perfectly described info for what I was looking for. I greatly appreciate your time and effort to provide this Thank you so very much.

 

So if I were to leverage the sub-pools, do I still need a basic cache pool? I'm sorry, I am very new to this...

 

I can send the NVME's back and get larger and/or more to do this (more) correctly. The z690 has 5 NVMe slots. I do anticipate a large plex library, should I go for larger NMVE's? One thing I don't know is if I find that I need more space for these cache and/or subpools later, if it's easy to add to later or not..

 

Thank you again and have a wonderful day!

Edited November 21, 20241 yr by jlwitherell
clarity

Summary

If you’re new to ZFS, start simple:

Use a single RAID-Z1 NVMe pool to get familiar with Unraid and ZFS features.

Upgrade drives or implement sub-pools as your workloads grow or needs become clearer.

Monitor performance metrics for bottlenecks (e.g., Plex scans, VM I/O) to decide when to implement SLOG or metadata pools.

 

Do You Still Need a Basic Cache Pool If Leveraging Sub-Pools?

not really. cache is more for disk in the array... when using zfs only its best to do that as a pool.

 

You don’t necessarily need a traditional Unraid cache pool if you are fully leveraging ZFS sub-pools, especially if:

You configure special metadata pools and L2ARC for read caching.

You use a dedicated SLOG for write-heavy workloads (like VMs or video editing).

However, having a basic cache pool can simplify:

Staging writes before moving them to the array.

Hosting Docker containers or VM appdata for higher performance.

If simplicity is your goal, you can skip the sub-pool approach for now and start with a traditional cache pool (RAID-Z1 or mirrored NVMe). If you later find performance gaps, you can implement sub-pools for more granular control.

 

 

Should You Get Larger NVMe Drives?

Yes, if:

 

1 Future-proofing: Larger NVMe drives allow you to handle increased Plex metadata, VM needs, or Docker workloads.

2 Sub-Pool Flexibility: With larger drives, you can dedicate specific NVMes for SLOG, L2ARC, or metadata pools without feeling constrained by capacity.

3 Performance Consistency: Keep drives of the same make/model to avoid mismatched speeds and partition block sizes.

 

A 2TB or 4TB NVMe drive is ideal for heavy workloads and frequent metadata updates in large Plex libraries. With five slots available on your Z690 board, you have room to scale.

 

Is It Easy to Add More Space to ZFS Sub-Pools Later?

 

ZFS doesn’t allow direct expansion of individual vdevs (e.g., adding more drives to an existing RAID-Z1 or mirror). Instead:

 

You can add new vdevs to an existing pool (e.g., add another RAID-Z1 or mirror set). This increases overall pool capacity.

Plan your initial layout carefully to minimize disruption when scaling.

 

For example:

Start with a 2-drive mirror for metadata and L2ARC. If you outgrow this, add another mirror set with two larger NVMes to the same pool.

 

Recommendations for Your Setup

1. Main HDD Pool (4x 22TB RAID-Z2)

Stick with RAID-Z2 for data redundancy. Perfect for a media server.

 

2. NVMe Cache and Sub-Pool Setup

Option 1 (Simplicity): Use all three NVMes in RAID-Z1 for a cache pool.

Pros: Easy to manage, good redundancy, suitable for most workloads.

Cons: Lacks the granularity of sub-pools.

Option 2 (ZFS Advanced Setup):

 

1 NVMe for SLOG: If you plan to use synchronous writes for VMs or video editing.

2 NVMes in a mirror for Metadata and L2ARC:

 

Benefits Plex, especially with a large library.

Great for fast filesystem traversal and metadata-heavy tasks.

 

3. Larger NVMe Drives

If budget allows, upgrade to 2TB or 4TB NVMes for greater flexibility and future-proofing. Use identical drives for consistency.

 

 

Man, I truly cannot thank you enough. You have laid out and answered all of my questions. And done so in a way that such a newbie like me can comprehend. I think that I will get some larger drives and leverage the sub-pools. I know I still have a lot to learn and it's not the easiest way, but I like a challenge. How do I buy you a cup of coffee or something?! Thanks so much again, and hope you have a great weekend

 

Oh wait, I see your gofundme. I'm sorry I didn't see that earlier. I hope your health turns for the better very soon, I'm very sorry to hear that. I am donating now.

Edited November 22, 20241 yr by jlwitherell

Thank You. i will gladly help where I can.

Hey bmartino hope all is well! Ordered x4 4tb sn850x NVMe's, but doing more research may be over-kill for SLOG/L2ARC? Also, I've seen info that I may be hard pressed to really need an L2ARC, given already having 128gb of ram (though this could change with say maybe 5+ people streaming 4k?).

 

From what I'm reading is that for the slog, very little capacity is needed since the system refreshes every 5 seconds, though that can be changed. I may still do both, but use the smaller drives and not mirrored. For the special VDEV, I would still plan to mirror two 4gb NVMe's, but what I've also since read is that maybe that's not a good idea with these unless they are Intel Optane, due to significantly lower write lifespans. Do you know if this is really something to worry about? Guess I'm a little nervous even mirrored as it seems if doing the special VDEV, that if these go back the whole pool goes bad. 

I never really messed with the defaults on unraid more in truenas. While unraid can do these things, I think they are still terminal commands. as zfs on unraid still needs a bit more polish. At this time, I can give general advice. as my setups are more towards data protection then performance. As this would be more towards performance tuning as the hardware presented would be more then capable.

 

Your bottleneck if any on mutiple strems of 4k would be (network access) and transcoding depending on file types in the server and how they are being played. Plex? jellyfin?. This is where jellyfin may preform better due to plex complexity in setup. the new intel ark cards are great for transcoding...

 

My Recommendations:

Assess Workload: Determine the typical workload and access patterns. If your workload involves heavy synchronous writes, investing in a high-endurance SLOG device like Intel Optane is beneficial.

 

Monitor Performance: Start with your current setup and monitor performance metrics. If you notice bottlenecks in read or write operations, consider adding or adjusting SLOG, L2ARC, or special vdevs accordingly.

 

Ensure Redundancy: Always mirror critical components like the special vdev to prevent single points of failure that could jeopardize the entire pool.

Stay Informed: Regularly check the health and endurance metrics of your NVMe drives to anticipate and mitigate potential failures.

 

#########

 

When configuring a ZFS storage system, it's crucial to understand the roles and requirements of various components like SLOG (Separate Intent Log), L2ARC (Level 2 Adaptive Replacement Cache), and special vdevs. Let's address your concerns:

 

1. SLOG (Separate Intent Log):

Purpose: Enhances performance for synchronous write operations by providing a dedicated, fast storage area.

Capacity Needs: Typically, a small capacity suffices, as the SLOG only stores data temporarily until it's written to the main pool.

Drive Selection: High endurance and low latency are paramount. While the WD SN850X NVMe drives are high-performance, they may not offer the endurance levels of drives like Intel Optane, which are often recommended for SLOG due to their superior write endurance and consistent low latency.

 

2. L2ARC (Level 2 Adaptive Replacement Cache):

Purpose: Acts as an extension of the main memory (ARC) to cache read data, improving read performance for frequently accessed data.

Necessity: With 128GB of RAM, the ARC can handle a substantial amount of caching. L2ARC becomes beneficial when the working dataset exceeds the ARC's capacity. For instance, with multiple users streaming 4K content simultaneously, L2ARC could help if the data isn't already cached in ARC.

Drive Selection: Similar to SLOG, L2ARC benefits from drives with high read performance and endurance. However, since L2ARC is a read cache, the write endurance requirement is less stringent than for SLOG.

 

3. Special VDEV:

Purpose: Stores metadata and small files to accelerate metadata operations and improve performance for small I/O operations.

Reliability Concerns: The special vdev is integral to the pool's integrity. If it fails and isn't mirrored, the entire pool can become compromised. Therefore, mirroring the special vdev is highly recommended to ensure data integrity.

Drive Selection: While Intel Optane drives are ideal due to their high endurance and reliability, other NVMe drives can be used if they offer sufficient endurance. The WD SN850X drives have good performance but may not match Optane's endurance levels. Monitoring their health over time is advisable.

 

#######

 

I would recommend a zfs only approach.
review:

 

also see:

 

other notes i have been using on this post:

 

and

 

 

To configure a ZFS pool with features like SLOG, L2ARC, and special vdevs on Unraid, you'll need the ZFS Master Plugin or terminal access. Here's a example guide for setting up each component:

 

With zfs master plugin on beta 7 installed we can create teh zfs pool
*Recommend in the gui will past terminal commands.

*Create in unraid web UI as a Pool first!

Create a Basic ZFS Pool

Using the ZFS Master Plugin:

Open the plugin interface in the Unraid GUI.

Click Create Pool and add the desired drives.

Choose the redundancy level (e.g., RAID-Z1, RAID-Z2).

*You want to make sure the # of vdevs. for performance 1 vdev across of 4 or more disks

# Example to create a RAID-Z1 pool named "mypool"
zpool create -o ashift=12 mypool raidz1 /dev/sdX /dev/sdY /dev/sdZ

 

Add an SLOG (Separate Intent Log)

The SLOG device should be fast and high-endurance (e.g., Optane). Adding it: Using the Plugin:

In the pool settings, select Add SLOG.

Assign your NVMe drive.

# Add SLOG to an existing pool
zpool add mypool log /dev/nvmeXn1

 

Add L2ARC (Read Cache)

Using the Plugin:

Go to the pool configuration.

Select Add Cache Device.

Assign your NVMe drive.

# Add L2ARC to an existing pool
zpool add mypool cache /dev/nvmeXn1

 

Create a Special VDEV

The special vdev stores metadata or small files. It requires mirroring for redundancy. Using the Plugin:

In the pool settings, select Add Special VDEV.

Assign two NVMe drives for mirroring.

# Add mirrored special vdev to an existing pool
zpool add mypool special mirror /dev/nvmeXn1 /dev/nvmeXn2

adjust setting of ZFS. Done before hand in zfs master plugin and at pool creation.

# Enable compression
zfs set compression=lz4 mypool

# Set sync writes to use the SLOG
zfs set sync=always mypool

 

Monitor Pool Health

Using the Plugin:

Check the ZFS Master Plugin dashboard for health and performance metrics.

 

# Check pool health
zpool status

# Monitor SLOG usage
zpool iostat -v 1

 

Additional Tips:

Optimize ZFS for SSDs: Use ashift=12 for 4K alignment.

Plan for Backups: ZFS is robust but not infallible; always have backups.

Test Configurations: Experiment with small datasets to validate your setup.

By combining the Unraid GUI and terminal commands, you can effectively configure and manage advanced ZFS features like SLOG, L2ARC, and special vdevs.

 

Fantastic information as per usual my friend, thank you. Good to know about the NVMe's being not a complete no-no, but just make sure mirrored and monitored - specifically for the special vdev/slog. Your first sentence also brings up another question. Since the hardware I have would be good for zfs (now and going forward), do you think that I should use truenas instead? Again, I'm new to this and basically got into the direction of unraid from my initial searches, and namely before diving into, or even knowing about zfs. Seem that unraid is likely better for their traditional array and if you have mixed and matched hardware (drives), but, since zfs has been established longer in truenas, should I just go there instead?

Edited November 26, 20241 yr by jlwitherell

It comes down to what you want the system to do and how you want to interact with it. For me, Unraid was the better choice after weighing the pros and cons, and it still is.

 

Correct—Unraid was built on Slackware Linux and is known for its array setup, which supports a mix of different-sized disks. With Beta 7, Unraid is experimenting with and allowing the ability to use pools only, without the array. It’s a bold but necessary evolution for Unraid as they progress.

 

A standard RAID setup requires disks of matching capacity. For me, Unraid is all about Docker. I can run just about any Docker system instance quickly and easily.

 

I left TrueNAS due to their issues with Docker support and the big fiasco since Bluefin, which essentially broke the Docker underlying system.

 

Does today's TrueNAS SCALE work? Yes. Do I recommend TrueNAS? Only for NAS-based systems: disk management, Samba, and NFS—NOTHING MORE! I would recommend using a VM of Ubuntu with Portainer for true Docker access and setup, but you lose performance due to VM overhead.

 

However, it is possible to run Plex through their Helm apps. I initially started with TrueNAS Core/Scale when SCALE was new and had my Plex instance running there before migrating to Unraid. I submitted quite a few workarounds, but in the end, I got blocked. They made it very clear that while it’s a Debian-based OS, they are mimicking and using FreeBSD while also experimenting with K3/K8 implementation—and they still haven’t chosen a side.

 

I could rant on, but the point is, I'm still a bit salty about TrueNAS breaking multiple systems in their effort to deliver what they claim may now be a stable NAS. While I can tinker and work around issues on Unraid, TrueNAS often broke things and implemented a "block it" approach. (I still have emails and other communications with their support...)

So, sorry—use TrueNAS at your own risk. While I'm sure it would be easier for disk setup and management, I can't guarantee a working Docker experience, especially with updates and security patches.

For your needs, I might recommend TrueNAS SCALE (stable, current version). X-systems are fixing things, but their last major build updates and fixes made it hard for me to trust their releases. TrueCharts has kept them alive in terms of Docker-like systems and the proper implementation of K3. The initial releases > Bluefin > stopped at Dragonfish. Check out YouTube channels like Craft Computing or Linux with Proxmox HBA pass-through running TrueNAS.

 

Download TrueNAS SCALE: TrueNAS SCALE 24.10.0.2

https://www.truenas.com/download-truenas-scale/

 

Previous versions: TrueNAS Downloads

https://download.sys.truenas.net/

 

They need to fix a lot for me to use them again. I was going to bite the bullet and deal with it without sharing the workarounds (to avoid being blocked). They’ve since added warnings but allow access to the Debian instance. Still, I don’t like the "Helm"-based approach—similar to an enterprise disk shelf setup with Ceph. Helm is meant for clustered systems, and while Docker works with one system, it opens up issues of XYZ. (Rant incoming…) With Unraid removing macvlan as the default, it almost killed Unraid for me. I shop around and explore XYZ groups, mainly because I’m the system admin for friends with a lot of randomly acquired PC hardware over the years. So, there’s a lot of repurposing of old hardware and a multitude of setups.

But yes, TrueNAS has a developed community that can meet your needs:
TrueNAS Forum - L2ARC/SLOG/Metadata Help

https://forums.truenas.com/t/help-with-l2arc-slog-metadata/6625

other potential candates:

Proxmox more for vm and lxc. not as a nice setup on zfs but can be done in termianl. 

 

There’s also Rocky Linux and 45Drives. While Docker will run on those, it’s mostly managed through the terminal.

 

Alternatively, you could go fully terminal-based and use a Linux distro. Unraid is a specialized distro for running NAS software (Samba/NFS servers) and has a community supporting its Docker implementation. The same can be said for other projects.

sorry for the rant 

 

 

Edited November 26, 20241 yr by bmartino1

He Bmartino thanks again for all the info. I have been busy but back to trying to figure this out. One question about this potential setup that has popped up is should I designate an SSD for docker installs and/or appdata for performance, in addition to the special vdev, slog, L2ARC, or is this not necessary with having these subpools? My apologies again, still a first time newbie. 

 

I'm also confused on the z master app. I installed it, and went to create the pools, but I can't seem to get zfs master to create anything. In Unraids gui I creat the main pool of spinners and zfs master will only see it when I start the array. Then, that pool shows up in zfs master but the only way I see to create the sub pools is from within the pool devices, nothing like that in zfs master. I have been searching for a step by step guide for a bit, but so far have been unfruitful. I know that I should be tweeking some of the parameters for the sub pools which I still need to also figure out how to do, then figure out how to use docker/plex as well. 

no worries. Yes, i would have atleat 1 disk be a btrfs for unraid (mroe the swap plugin) as the cahced drive. In adition to subpool disk assimnet for the L2ARC etc...

Usually a btrfs single disk called cache exist for Unraid. The default pathing had the appdata folder on the single cache pool disk array.
when using CA the template defaults to using /mnt/user/appdata

 

as long as you change teh path to zfs /poolname/etc...
it doesn't matter where dockers and appdata is stored. in my case I put them on my zfs pool

However, some docker like running a database are disk read write intensive. You would want that on a single ssd/nvme for performance. and not taxing the #of disk in the zfs pool setup.

for plugin specific question and help I'd have you ask on their forum.

The zfs master plugin, for me is more a Main tab view of my zfs stuff like dataset and space. If running beta7 RC1 you would use part of it to run the zfs terminal commands in the web UI or use the share tab to make a new dataset.

 

You may need to hit the refresh or gear to set some settings:

 

 

SSD for Docker and Appdata:

Recommended Setup:
It can be beneficial to dedicate an SSD or NVMe drive specifically for Docker and appdata. This setup improves performance by keeping frequently accessed files on faster storage.

Why Use a Separate SSD?

Even with ZFS subpools, Docker containers and appdata benefit from low-latency storage. ZFS caching mechanisms (like L2ARC) are read-only caches, so Docker write-heavy workloads won’t be helped as much by them.

 

Understanding ZFS Master App in Unraid:

Creating Subpools:

ZFS Master typically only recognizes pools created once the array is started. This is normal behavior due to how Unraid handles storage initialization.

Creating Subpools:
You won’t create subpools directly in ZFS Master but through Unraid's GUI or command line (zpool and zfs CLI tools).

*This has recently been added to the web UI with beta v7 that i have found per the youtube videos above)

with the array stopped, you can add sub pools via the web ui:

 

Key ZFS Tweaks for Unraid:

Special vdevs: Use this if you want metadata, small files, or deduplication tables on fast storage.

SLOG (Separate Intent Log): Use if you need sync write performance, typically for VMs or databases.

L2ARC: Use only if you have more RAM and expect large working sets.

 

Procedure Overview:

Create the main pool using Unraid’s GUI. start format then stop array. You should see areas to add sub pool in the main tab

use main tab to create and Adjust dataset properties with zfs set commands (e.g., compression, record size). Otherwise use the share tab to make a generic zfs dataset no comporesss or encryption.

 

I have no need for slog or l2arc:

 

 

Resources and Next Steps:

Unraid ZFS Guides: Look for community posts on the Unraid forums or YouTube tutorials.

CLI Tips: Consider learning key zfs CLI commands for flexibility. (You can always ask onthe forum.)

Docker & Plex Setup: Once your pools are set up, follow standard Unraid guides for Docker and Plex setup.
*It more on how and where you want the data stored.

 

?what issues do you have with plex?
gpu passthorugh for transcoding: 

 

or general template options and settings?

https://docs.unraid.net/unraid-os/manual/docker-management/

Thanks, as always very good information for me to make the next steps. Now I'm pretty sure I can set up the pools, but I need to figure out which tweaks to make along the way (block sizes allowed somewhere I think I need to look at - all for best performance type stuff). Then figure out how to do the dockers/app data and install them to the single SSD.. (?), and figuring out their configurations. But yay, I think now, with just figuring out a little tweaking of the subpool setups I can at least get the whole thing framed (I had a video regarding some of the tweaks when using sub pools, but need to try an find that again and/or and also do a bit more research). 

if you leave the cache pool alone, unraid will default the docker appdata share there. so the "Program files" installed form unraid for dockers will by defualt be on cache btrfs disk drive.

Other zfs related videos:
 

 

 

 

 

Ah, that's great to know and thanks for the videos. I think I've watched the 1st and 3r one, I'll watch these and a few others again. Thank you again for all of your help, hope all is well

You mentioned earlier about formatting the single NVMe used for appdata/dockers as BTRFS. I should not do that as zfs too? This does does not have a mirrow, so with zfs could do snapshots if wanted?

Edited December 15, 20241 yr by jlwitherell

Recommend yes, but 100% optional...

 

The reason more comes from maintaining the orginal unraid single disk cache pool where one/I can use a user script taht can be called to back up docker data into zfs...
This was more for using the unraid swap pluigin and having a btrfs formatted disk and a single fast disk for some dockers that don't make sense existing on a zfs pool disk setup.

its optional. More For backwards compatibility with unraids default stuff, As I would still recommend having appdata on a single cached btrfs disk. then move or add the other system folder for the vm/docekr service where the libvirt image file and docker xfs image file live/exist on...

This then leaves the docker application and "Program data" form any CA tempalte to install on and running from a single disk. and important data like a plex media libary, pictures, etc are stored on zfs with redundancy. As I can always remove/rebuild the system.img and reinstall a docker, but the docker data used is stored in a better zfs system. and ran from a single read disk.
*helps lower zfs read writes to prlong disk usesage and age. as these 16 TB disk have lasted me more than 10 years now and about to hit smart power on hours and useage....

then one/I can use other plugins... like using tools like the appdata backup plugin or user script to periodical backup/copy working docker data from the single use to the zfs system.

This is why I have a dataset called backup and dataset called docker.
my docker data exist in there with each container having their own sub directoy

and I can easy backup/restore system from the working drive to/from my zfs for recovery in the backup folder. Backup folder then becomes a staging folder in my setup and the chose dataset hierarcy for later rsync off to follow the 321 backup rule.

Delaer choice and how they want to interact for the inevitable recovery process and minimize downtime. to recover.
With unraid pool on zfs it easer to swap a disk and resliver.

when the single btrfs disk dies. i replace and copy dat back to restore dockers. the appdata has a nice restore function as well...

I chose to keep a btrfs disk more for other plugins and side testing.
While i recommend it is not necessary