If you have a NAS, then just put iSCSI disks on the NAS, and network-share those iSCSI fake-disks to your mini-PCs.

iSCSI is "pretend to be a hard-drive over the network". iSCSI can exist "after" ZFS or BTRFS, meaning your scrubs / scans will fix any issues. So your mini-PC can have a small C: drive, but then be configured so that iSCSI is mostly over the D: iSCSI / Network drive.

iSCSI is very low-level. Windows literally thinks its dealing with a (slow) hard drive over the network. As such, it works even in complex situations like Steam installations, albeit at slower network-speeds (it gotta talk to the NAS before the data comes in) rather than faster direct connection to hard drive (or SSD) speeds.

Bitrot is a solved problem. It is solved by using bitrot-resilient filesystems with regular scans / scrubs. You build everything on top of solved problems, so that you never have to worry about the problem ever again.

That's not what storage engineers mean when they say "bitrot".

"Bitrot", in the scope of ZFS and BTFS means the situation where a hard-drive's "0" gets randomly flipped to "1" (or vice versa) during storage. It is a well known problem and can happen within "months". Especially as a 20-TB drive these days is a collection of 160 Trillion bits, there's a high chance that at least some of those bits malfunction over a period of ~double-digit months.

Each problem has a solution. In this case, Bitrot is "solved" by the above procedure because:

1. Bitrot usually doesn't happen within single-digit months. So ~6 month regular scrubs nearly guarantees that any bitrot problems you find will be limited in scope, just a few bits at the most.

2. Filesystems like ZFS or BTFS, are designed to handle many many bits of bitrot safely.

3. Scrubbing is a process where you read, and if necessary restore, any files where bitrot has been detected.

Of course, if hard drives are of noticeably worse quality than expected (ex: if you do have a large number of failures in a shorter time frame), or if you're not using the right filesystem, or if you go too long between your checks (ex: taking 25 months to scrub for bitrot instead of just 6 months), then you might lose data. But we can only plan for the "expected" kinds of bitrot. The kinds that happen within 25 months, or 50 months, or so.

If you've gotten screwed by a hard drive (or SSD) that bitrots away in like 5 days or something awful (maybe someone dropped the hard drive and the head scratched a ton of the data away), then there's nothing you can really do about that.

This is what I use, will work with any filesystem (it writes hashes in hidden/dot files) and on any OS as long as Python is available: https://pypi.org/project/chkbit/

It runs ahead of my nightly backup. If it fails, the backup won’t proceed.

Edit: Because the script relies on hashing files, it uses tons of both disk IO and CPU when it runs, but the tradeoff is worthwhile to me.

Yeah, that's kind of what I expected and I am now thinking of keeping my setup how it is currently and getting a mini PC for less important data and services to tinker with.

For any family photos and documents you can't afford to lose, make sure you have backups of it. A RAID array does not mean you don't need backups: you want at least 3 copies, at least one offsite.

The copy in your RAID array is one copy. You can back that up to an external hard drive or something as a second copy. Then have an offsite backup on something like Backblaze as your third copy.

Save yourself a headache and use btrfs/zfs with periodically checks as suggested in another post.

Who cares if it is a problem or not when it has a simple and inexpensive solution.