foo_fighter

What are the best practices to create single zfs disk in Unassigned devices and then add them to the array later or pull devices out of the array and have them mountable in UDev? Especially with pool names? Something seems to be different with these disks: 1 is not mountable in Udev, even though it was mounted in the array. The other 2 are mountable. It seems to have something to do with the pool names. Here is the zpool import for sdc which was mounted in the array as disk7: pool: disk7 id: 10683320168744557805 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: disk7 ONLINE sdc1 ONLINE How would I make it mountable in Udev? How would I make future drives mountable in both Udev and Arrays? Thanks

Stopping and starting the array seems to have fixed the issue.

This may not be an unbalanced or rsync problem but I seem to be missing an entire zfs mount after running unbalanced to move files from disk4 to disk3. zfs_master and zfs do report the directories and the correct sizes but I can't seem to see them: zfs list: and zfs_master in the gui seem to match: but I cannot see any of the files or run ls or du on them: One clue is that I might have possibly formatted another spare disk outside of the array and tried mount it with pool name "disk3" but it errored out and then I renamed it using the serial number and it formatted and mounted fine with unassigned devices. Any advice on how to proceed? I was about to stop the array to unmount everything and then restart the array. diags attached tower-diagnostics-20241223-1953.zip

You don't really need to do anything. That's the beauty of UnRaid. The config is on the flash drive and is portable. However, I would suggest: On the new system, make sure the devices show up in BIOS. Run memtest on the new system to verify the ram. If you're changing from non-UEFI to UEFI, you might need to rename the EFI- directory on the flash to EFI. After booting, you can re-run the sensors-detect for dynamix if needed

An external USB dual dock is very handy. Your procedure will work, if you zero'd the 4TB drives, you shouldn't need to re-create parity. You can just check it to make sure it's still valid after you remove them, then pre clear the 2 drives and do the same thing, verify parity is still valid. Parity should stay valid the whole time.

Preclear both new drives first, you can use USB to pre-clear if you don't have enough slots and you can swap while the server is running. If you already unbalanced the 2 4TB drive and zero'd them, then just removed both and add 1 pre-cleared drive and check/sync parity, then add the other drive as parity2.

Is a benefit of this being able to snapshot and rollback individual docker containers? Let's say an update breaks something. If my cache has ZFS snapshots, can I roll back the offending docker's dataset?

There's a bug in the current detection mechanism. You need to put your disks in the "Monitor disks outside array" tab.

Are these types of BTRFS "Linux Raid Members" not mountable with unassigned devices? They were single disk standalone volumes.

flash is under /boot. You may need to store files there and copy them to where they need to be on reboot using the /boot/config/go file. For example: #Copy bash profile cp /boot/config/bash_profile /root/.bash_profile

You can also copy a backup of the .xml file for reference or to diff, just don't make a backup directory as there is a bug that will pull the file from that backup directory instead.

Get a CMR disk for parity and keep the SMR disks as data. I've had 1 8TB SMR for years as data and it's been fine and doesn't seem to have any performance impact, but it seldomly gets written to.

The last steps are redundant if you're rebuilding parity anyway. 1) Change all my shares inclusion settings to write new data only to disk 5 & 6. 2) unbalance all 4x4TB drives (disk 1-4) I would modify step 2 slightly to not move, but copy the data so you have a backup 3) Initiate new configuration and unassign Parity 1 & 2 and assigning the new 20TB drive to be parity 1 and remove 4 X 4TB drives. 4) Let parity rebuild occur while I keep my old parity drives and 4 X 4TB drives off to the side. 5) Parity rebuild completes and I Preclear the old 12TB parity drives in unassigned devices and then add them to array when ready. Triple check all data before pre clearing the old 12TB, since this is the last time you can go back to the previous config. Let us know how it goes.

A 2 disk array is a special case though, since parity will be a mirror with a complete filesystem and everything. It would be cool if unraid could recognize this to make things like scrub/repair possible. Maybe a 2 disk array is too much of a limited corner case.

For #3, you'd need to pre-clear them which writes all 0s to the disks in order to keep parity sync'd, format alone won't prevent parity sync. You've got enough space to unbalance the drives now. So you could: unbalance the 4 4TB drives while you have dual parity. Add the single parity, and sync and verify. pre-clear the 2 12TB drives outside of the array. Add the pre-clear'd disk into the array without parity sync. You can split the last 2 steps into 2: Add the 20TB as parity1, then pre-clear the old parity 1 and then add it back into the array while it still has dual parity. Remove dual parity only when you run out of data space or get another 20TB and then add the 12TB as data while keeping dual parity. Another approach would be to add the 20TB as parity 1 and then replace any of the 4TB with the 12TB(rebuild the 4TB onto the 12TB) and rise and repeat gradually as you need more space.

How did you fry all of the drives with a PSU swap?

Do you have it set up as a mirror? So 2 512GB drives would be 512GB total but mirrored on each drive(each drive has a copy of the same information).

Are you using a UPS?

In the US, places like serverpartdeals or goharddrive offer their own 2-5 year post sales warranties for recertified drives. I'm not sure if there's something similar in Australia or if they would ship there for a reasonable price.

I favor generally what is the best $/TB in the current market with maybe a slight premium for larger capacity. Larger capacity drives have been shown to have similar reliability in terms of failure rates(back blaze studies) even though they are more complex with more platters and heads. They also have the power/heat/port advantages. The smaller drives eventually become fairly useless, no one really wants low capacity drives anymore. Cloud backup for media seems like it would be expensive. The media itself is backup for the array. I guess you've got to compute the $/hr of your time to re-rip it in a worst case scenario. I've got one system with 1 parity disk protecting the data(3 18TB drives) and another system that's a backup but with no parity protection that syncs nightly and shuts down. I'll probably add parity to the 2nd system at some point. I'm not using ZFS pools, but I do use ZFS for the cache and 1 ZFS disk in the array. There are pros and cons to each approach but I wanted to avoid having all disks spinning to access data and ZFS wasn't well supported in unraid until relatively recently and expansion was a pain. ZFS replication from the cache to the array is pretty handy. ZFS scrub is also nice but in my system I don't have the benefit of autohealing that a true zpool would have. The whole beauty of unraid is that you can easily add a data disk at anytime and also increase from 1 parity disk to 2 parity disks if your array grows. Not so much with zpool vdevs. If you build a backup system, that seems like a good 3-2-1 protocol with the original media as the 3rd source.

Powermode is set using the settings page of UnRaid. I honestly didn't check all 3 modes. powertop --auto-tune can be added to your go file under /boot/config/ You can first run it by logging into console and running it on the command line to see if it helps. If it does, add it to your go file.

Sounds like a good plan. To be extra safe you could: run scrub and smart checks first on your existing BTRFS pool. If you want to be super-duper extra safe, run bunker or the dynamix file integrity tool and save all of the b3sum/md5sum hashes to file attributes on the existing pool. Don't use mover, run rsync -avX to copy the files over to the external drive and run bunker -a to re-verify on the external drive everything was copied and verified correctly. Keep the nvme pair as a backup. You don't really need to nuke the whole usb, but it's fine if you want to. Keep a copy of the config/key as suggested.

I believe you can make a single disk ZFS drive and turn it into a mirror later, but not a mirror to a raidz config, at least not yet. For OP, it'd be easier to move all of the data off to another disk like an external disk, put all of the new NVMEs in a new pool with the config you want (raidz1 or z2, etc) and then move the data back. 1TB isn't too much data to move around.

To answer your other question, if you go with ZFS pools, then you won't be using "UnRaid," at least not the original concept with a parity disk(s) and only spinning up the drive being used. All of the disks in your ZFS pools will be spun up to access data. It would seem like fewer disks in a RaidZ2 pool would be more fault tolerant(better MTTF overall) and address the 2 disk failure case. Also RAID isn't backup so if you lost the vdev, you would just restore from backup worst case. 8TB drives might be cheaper per drive but 18TB would be cheaper in total since $/TB is better. Also electricity costs would be 2X with more drives plus added heat. Also running out of drive bays/controller could be an issue, for example for spares/swaps. Software RAID(ZFS) or UnRAID is actually more tolerant of non-NAS drives, but I would avoid S(shingled)MR drives for performance reasons. NAS drives are rated for longer MTTF and continuous workloads(24x7x365).

Have you considered larger capacity drives? 18TB seems like the sweet spot now. ~$150-160 for recertified drives with warranty.