Home NAS build, FS info

Zitat von lebrac

3x WD-RED 4tb [...] I was thinking about a RAID 5

That's 8 TB data so you need at least another 10 TB for backup (if you opt for RAID and you seem to need 24/7 data availability then I would assume the data has some value and needs a backup too?)

RAID is not backup. It won't save you from malware, accidental deletion, file corruption, etc...

Zitat von lebrac

Why another backup?

With your planned setup you have no backup at all. It's easy to test whether your backup is sufficient. Just do a 'sudo rm -rf /' and see what happens. With a 'good backup strategy' that includes desaster recovery you're up in no time again, with 'RAID only' everything is lost.

The R in RAID is only useful for 'business continuity' or availability. No data security, no data safety, no data integrity. It's just an absolutely insane waste of resources at home.

I use RAID5 for my MediaCenter storage. I do monthy backups offsite (encrypted to the 'cloud').
RAID 5 is sufficient in case of a disk crash, note "A" disk-crash. If more disk dies when you rebuild the array (which happens more often than one would believe), you surely want to have a backup.

Another off-sync/site backup is also crucial in case of malware that renders your files useless, like ransomware. It has already been mentioned.
RAID is not backup, it is a operational redundancy. Backup systems should use RAID, but never assume RAID is backup in itself.

Zitat von lebrac

At this point you are saying that I don't need raid at all?

Most probably you don't need RAID, yes. Since you already confused redundancy with backup (data safety) I would recommend to check/adjust your expectations wrt the technologies you plan to implement.

Redundancy sounds like a good idea but most people blindly trust in it, forget the important parts (eg. backup), don't test anything (especially not the worst case situations) and then even some minor problems occur and everything is lost. RAID5 can cope with a single 'Boom! Disk dead' occurence, primitive RAID5 implementations then might fail after replacing the failed disk when a single defective block on any of the two remaining disks occurs dropping the whole array and most RAID implementation do a really bad job when disks start to die slowly. No idea whether that applies to OMV since we phased out support for RAID5 over a decade ago.

At customers it's double or triple redundancy these days (so RAID6, zraid2, zraid3 or proprietary variants) or even zmirrors since in the meantime not only data lives on the storage boxes but also VMs that have a demand for high random IO. And for my own purposes (both work and personal stuff) I also dropped RAID entirely and prefer 'data separation'.

In other words: no clear recommendation, only asking to adjust your expectations and care about the important stuff (data safety, data integrity, most probably not data redundancy -- that's the R in RAID)

Zitat von lebrac

What about the filesystem?

Well, it's 2017 and for a NAS I would use none of the filesystems that originate back 30 years ago but only either btrfs or ZFS since they implement concepts like snapshots, data integrity, a more flexible 'layout' and also transprarent filesystem compression. But to be honest: I still don't know much about the level of ZFS integration in OMV since my ZFS boxes run with (Open)Solaris, FreeBSD/FreeNAS, Open-E (commercial) or Ubuntu Xenial 16.04 (since zms dmks integration).

I explored OMV on cheap and energy efficient ARM devices so far (btrfs with compression runs pretty well on small boxes likeNanoPi NEO2) but it will take some time to get into all the advanced stuff (especially since I'm thinking too complicated based on experiences with other platforms/solutions before and using my own solution of scripts to 'back up' snapshots I do at one location to the others). So I'm not of much help here, just wanted to point out that you should think about which technology you choose is good for what.

Wrt RAID 0: why? If it's only about combining two disks I would choose span/concat mode instead (don't know the OMV wording) that simply uses two disks in a way that data will be written to disk 1 until full and only then starting to put data on the next disk. But honestly I like disks that spin down and try to separate data on different disks depending on usage patterns (so the disk(s) with movies on it will sleep 24/7 and only automatically spin up when we watch a movie)

Hello,
Please consider RAID1 with 2x 4TB WD Red + SSD for system drive, pendrive is bad idea, it will die faster and perform worse than HDD.
Also you should look on boards with integrated CPU, it will cost less than MB+CPU but performance will be same or even better.

As almost all admitted, RAID is not a backup, so buy external HDD and make backups - this is simple data safety, recovery and so on. RAID is useful only when your HDD is dying.

Zitat von kawu2

RAID is useful only when your HDD is dying.

How should it be 'useful'? RAID is only about availability (who needs this at home?). It allows to continue operation without interruption if a single disk COMPLETELY fails. It doesn't deal good or at all with other failures that happen way more often.

Then it depends on the implementation. RAID1 as done by mdraid can be considered worst case, it just TRIES to mirror the data so in case you have one disk with cabling/connector problems that are undetected there's a chance that different data is written to the 2 disks. Since mdraid only reads from one disk (not checking for mismatches) there's no chance to detect data corruption. You sacrifice another disk for redundancy and are protected just from a single very rare occurance (complete drive fail).

Compare with non anachronistic approaches (ZFS mirror, btrfs raid1 mode): here both data and metadata will be checksummed and these checksums are also stored redundant. When data is read, checksums will be calculated again, then compared and if there's a mismatch (data corruption) then it will be reported (monitor syslog), you can run so called scrubs regularly to check for this type of problem (or check error counters manually: 'btrfs device stats $mountpoint') and if you opt for redundancy then ZFS/btrfs are able to not only detect data corruption but also to repair. Since checksums are in place the corrupt copy of data can be detected and be replaced with a new copy. It's not exactly 'self healing' but protects from a lot more problems and is able to give you an indication of a disk starting to die (unlike mdraid, there it's just a message your disk has died eventually a few weeks later and you already suffer from data corruption that spread into backups too).

Using modern fs like ZFS/btrfs you do snapshots all the time, transfer them to another disk or machine and have therefore the ability to recover from situations where data corruption might have been occured as long as you didn't delete all the transferred snapshots already. Even without a second disk snapshots can be a life safer since disk failures happen less often than the other causes for data loss or corruption (software crashing for example).

BTW: Using mdraid's RAID1 is always wrong in the meantime: even if you want to use anachronistic methods that allow only for very low protection you choose RAID10 instead (archived version).