Why another backup? With the RAID 5 I can cover the failure of 1 drive, right? It's enough for my purpose.
My doubts concern the power of cpu for 1 transcode, the filesystem etc... I mean, with 3 disks raid5 is the only option right?

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.

Most of the data are not so valuable, I can have a backup of the valuable data (photos, documents ) in the cloud.
At this point you are saying that I don't need raid at all? Just a Raid 0 to have a 8 or 12tb, and use the nas for stream etc?

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)

Thanks, for your answer.
That's why I was thinking of a raid. At present, my main problem is also the continuity and availability of files: part of the important data is on "at risk" hard drives that are more than 5/6 years old and have many hours of use.
I can backup them in the cloud and use the raid0 nas for streaming and storing both important and not important data. Right?

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.

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).

The post was edited 2 times, last by tkaiser: Replaced broken Google cache link at the bottom with again working original link + archived version (Aug 8th 2018, 4:44pm).

From what I knew omv in a USB drive doesn't affects video streaming or data transfer speed...Only the overall speed of the system...Maybe the transcode I don't know...but, as I said, I have a "light" usage.

Also you should look on boards with integrated CPU, it will cost less than MB+CPU but performance will be same or even better.

Can you give me some examples please? I was pretty sure that Pentium g4560 + a cheap mobo were one of the best config for that price.

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)

Thanks for your answer, I meant concat of disks, but once again, I use the wrong terms.
At this point I'm convinced I don't need RAID at all, it's not worth it.