So I’ve been running a home media server with the arr suite on it, but it only has about 2 tb storage. The storage has been full for a couple months now which has rendered my server useless. Now I’ve bought a used nas with 32 tb on 7 disks. I’ve been advised to set it up in RAID. I’ve learned how to do that in OMV and it’s setting that up now.
It takes a while though, so that leaves me some room to think. Why do we do this? I understand that it gives me more unified storage, but I also want to run other things on this machine. Like k8s to deploy my own applications and play around with devops stuff. Or even just regular file storage and photobackup next to the films and series. I thonk I would like to keep those things seperate though, is that still possible with RAID? Or is it better to put 5 disks in RAID and keep the other two for other stuff? I think my question is, how do you use RAID “practically”? How do you store different things on there? Do you compartmentalize the disks again, or do you just make different folders?
I’d say yes to RAID in a NAS or server in general. Just see that you don’t purchase the disks in one go - that was the only RAID in the last 30 years to fail on me (five disks within 20 serial numbers, four of them failed in total, two within a night). Was a pain in the a… to restore stuff from tape, but at least i had them.
Well, it’s IT, so the answer is always a big ol’ fat, “It depends!”
Why do we do this?
Ostensibly, the primary reason for RAID is in the name: redundancy. Of course, there’s RAID 0, which is for performance, but that’s kind of a different thing that doesn’t seem to apply here. The main risks it mitigates are those associated with drive failures.
RAID isn’t, and should’t be considered, a substitute for backups. But, backups can be a substitute for RAID in some situations. If you simply want to avoid losing data, the right backups solution can do that for you, but your time to recovery will be longer; rebuilding a RAID disk from parity is much faster than restoring a backup from scratch.
So, if you want, you can RAID some disks, partition space on those disks and store your important data on the RAIDed partition. The rest can live on backed up but un-RAIDed disks. It’s really according to your specifically desired recovery time and risk appetite for that data.
A NAS has layers. If you RAID the 7 disks together they’ll act like 1 disk with fancy protections depending on the kind of RAID. After that you can setup volumes. I don’y have experience with OMV, but truenas and unraid do this so I assume omv does too. You can have one volume be for docker stuff, another for media, etc. Then within each volume you setup folders.
You can break up the RAID into as many logical volumes as you want. Well, there’s probably a limit, but I haven’t reached it.
What filesystem are you using? Generally filling a disk to 100% is a very bad idea as there isn’t any room to relocate sectors.
I personally recommend ZFS but it does require some knowledge to setup and maintain. Make sure you are booting off of a SSD as that will make the system much faster
As you said, RAID gives you a single unified storage pool from independent drives.
It also gives you some fail over if using RAID 6 with dual drive redundancy and hot fail over (which any modern RAID system has).
You can then divvy up the storage however you want. Single big drive with folders and file-system permissions, or split the pool into multiple logical drives, etc.
The world is your oyster.
For my needs I have a single big drive with folders, but only a single user on the RAID box has write permissions - and that’s an account from my file server.
The file server then handles shares, permissions, user names, etc, so I have a single point of user management and file access. Which isn’t really much different than what businesses typically do: storage management is separate from user/file management.
Lots of RAID systems today support LDAP, so you could theoretically manage user access on the RAID box, but I find that cumbersome, and prefer having a file server.
