Srsly, no-one going with the "it's free real estate" meme.
Jokingly, but also really, seems a waste. I get they don't want the overhead, but just boost it north, perhaps to a Lagrange, maybe just high orbit, but someone will come along to salvage eventually...
ETA: Also, one of the beauties of SpaceX is that Musk doesn't muck with it (yet), working too well without him, unlike everything else he's bollocksed up.
To a large degree, the point of RAID is to not care about drive reliability, trust the process. Also, you seem to conflate RAID with backup ("RAID is not a backup"), you want both. In a NAS, you're probably better off with RAID5 + backup.
In a system that can take a drive failure, the current datahoarder zeitgeist is Manufacturer Recertified (Enterprise) Drives, see ServerPartDeals.com if you're a yank, other countries have their own options.
I'd suggest you move toward a backup approach ("RAID is not a backup") first. Assuming you have 2x10Tb, get a 3rd and copy half of your files to it, disconnect it, and now half your files are protected. Save, get another, copy the other half, now all your files are protected. If you're trying to do RAID on USB, don't, you are already done, otherwise (using SATA or better) you can proceed to build your array in an orderly fashion.
The *arr suite, e.g. rando hard drive TV show, add show to sonarr, import (yes it's usually that easy), movies - radarr, seeking out stuff you're watching now - prowlarr. Quite mature and way easier than hunting through streaming services.
Sure, I was being mildly facetious, but pointing to a better pattern, the nature of python means it is, barring some extreme development, always going to be an order of magnitude slower than compiled. If you're not going to write even a little C, then you need to look for already written C / FORTRAN / (SQL for data) / whatever that you can adapt to reap those benefits. Perhaps a general understanding of C and a good knowledge of what your Python is doing is enough to get a usable result from a LLM.
When you need speed in Python, after profiling, checking for errors, and making damn sure you actually need it, you code the slow bit in C and call it.
When you need speed in C, after profiling, checking for errors, and making damn sure you actually need it, you code the slow bit in Assembly and call it.
When you need speed in Assembly, after profiling, checking for errors, and making damn sure you actually need it, you're screwed.
Which is not to say faster Python is unwelcome, just that IMO its focus is frameworking, prototyping or bashing out quick and perhaps dirty things that work, and that's a damn good thing.
