Take a look at this guide for general build information and how to get started.
_________________________________________________________________________
Things that would help, in advance, is at least some idea of the size of your data store. This would help you to determine what size and/or how many disks. In the guide, general guidance along these lines is provision storage that will house your current data store with a 25 to 50% fill rate. So, 6TB of disk real-estate would be a good start for 1.5 to 3TB. (This is GENERAL guidance.) Depending on the size of disks used, you'd have an indicator of the case needed, sata ports, etc.)
Traditional RAID,,, generally not a good idea. RAID is about availability, not redundancy and it's certainly not backup. (These are common misunderstandings.) If you fully backup your data store, to an internal or external disk, the risk of data loss is substantially reduced. Backup is far more important than RAID.
I have a preference for ZFS, but couldn't recommend it. It has great features and can be used right out of the box, but understanding what it is, how to use it's features, etc., takes a bit of time. I'm not using it for availability either. It's a zmirror (the rough equivalent of RAID 1) used solely for bitrot protection and self healing files.
The safe disk array alternative, if that's what you're looking for (combining disks into a pool), would be a combination of UnionFS and SNAPRAID. (They're simple and reliable but, again, if you haven't heard of them before there's a slight learning curve.)
The easiest possible way to set up a data store, with full backup, is with two disks (6TB each). Disk 1 is the data store, and Disk 2 is a full 100% backup, using Rsync. This can be automated and how to do it is in the guide.
If you want to expand later, UnionFS can be used to expand the data store and, with an extra disk added for SNAPRAID you'd have the functional equivalent of a RAID array. (But with better features when compared to traditional RAID.)
Transcoding requirements are in the guide but it should be noted that, if using a utility like handbrake, media files can be recoded to a native format for phones and tablets. (There's a video how-to for doing this automatically.) Without transcoding, streaming in a native format is rough equivalent of a slow file copy. Accordingly, CPU requirements drop dramatically.
______________________________________________
For Client backup, I'm using UrBackup with a separate 3TB drive that's not part of my data store. If you don't keep large data stores on clients drives (data really should be on a server) a 2 or 3TB drive will be sufficient for your client backup needs, as stated.
______________________________________________
In any server platform ECC is recommend along with some form of bitrot protection for the data store.
(Another excellent feature of SNAPRAID.)
______________________________________________
Before diving in with a hardware purchase, without really understanding what you need, have you got an old PC? You could build OMV on it and see if it's what you're looking for. Build OMV on a USB drive and use the internal drive as a data disk. (Or maybe buy a 6TB drive, install it, and go from there?)
I'll say this much from experience, OMV on x64 platforms is stable, easy to use, and highly extensible. If you go this way, I think you'll be surprised at the numerous server add-on's and Dockers available. From a simple (but technically sophfisticated) file server, to media servers, downloaders, a Virtual Box platform for virtualization, there's something in OMV for everyone.
QNAP? If you don't want to invest a bit of time and effort, maybe a QNAP is for you. On the other hand, you'll be shelling out a premium for the hardware and, when they stop supporting it (as all commercial products do), you might end up right back here, installing OMV on it as a new operating system.