ZFS Hardware requirements

It would work fine as long as you don't enable deduplication. zfs will use ram as cache if available. Just remember that if you create a three drive raid z1 (equivalent of mdadm raid 5) pool, that you will have to add three more drives to expand it.

For two users I'm running an i3 with 12GB (not necessary - 8GB would be fine) with a Zmirror.

While I'm using it for a backup, I'm running a second Zmirror with 4TB drives, using 4GB RAM and an Atom processor.
As ryecoarron says, without dedup, hardware requirements are not as stiff as some claim they are.

Quote from HannesJo

Don't you think ZFS may be some kind of overkill and I should better give SnapRAID (with EXT4 mdadm RAID5) a try?

Personally, I would use a filesystem that you are comfortable with if things go badly. snapraid on mdadm would be weird unless you have a parity drive outside the array. I would think about whether you really need raid 5. snapraid with mergerfs to pool the drives is a very stable solution. Your availability is a little lower because you would have to restore the files using snapraid (or backup) if a drive failed. But all of your files on the non-failed drive would still be available.

Quote from HannesJo

Rot bits actually occur astronomically rarely

OK, first realize that "astronomically" large numbers apply to modern day hard drives. Where talking about "terra-bytes" these days where 1 terra-byte is a Trillon bytes or 8 trillion bits. (Mathematicians, please chime in if I get the math wrong.) A good raw bit error rate is 1X10^-6 or 1 in a million. Even with error correction, 1x10^-6 can be improved to 1x10^-8 or even better, maybe 1x10^-9, but 1x10^-9 is still 1 error in a billion. In 1 terra-byte of data, with a BER of 1x10^-9, you'd be looking at 8000 bit errors.

To reduce the chances of bit errors, there are robust error correction schemes in play but when we're talking about trillions of operations, "stuff happens". (Static discharges, unknown ground issues, power problems, etc., can create infrequent bursts of errors.) And it only takes one (1) weak CMOS gate or a slightly dirty power supply output to generate an error, on occasion, or even intermittant streams of errors. The sources of these issues can be difficult to impossible to find. Given the shear "astronomical" numbers involved and the complexity of modern day computers, "something" should be expected to go wrong at some point. It's just a matter of time.

ECC RAM:
ECC RAM keeps data in memory from being corrupted. A flipped bit in ram might not affect hard drive data at all. If the flipped bit is in an executable, it might cause a program error, a kernel panic or something like that. When data from a drive is read into ram, corruption of "read" data in ram is not of serious consequence. Silent corruption could only be a factor when corrupted data is written to the disk. While ECC RAM reduces the chance of data corruption and is important in 24x7 server operations, serious corruption of data on a hard disk is more likely than the occasional "bit flip" in ram.

Hard drives:
Compared to just 10 years ago, it should be noted that the areal densities of hard drive platters are off the charts. Disks are packing bits in tighter and tighter, increasing the chances of running into minute imperfections in the media. Of note, for a variety of reasons, magnetic bits can and do flip or simply go flat (no polarity). It happens and this type of corruption is silent. (Setting that aside.)
Most people believe that hard drives fail all at once. That they work one day, and the next they don't. While a "light switch" like failure can happen, it's fairly rare. Magnetic media has a limited life (the platters), the mechanical parts begin to fail (motor, actuator and heads), and the interface electronics all are counting down toward eventual failure. The net result of failure is, typically, a hard drive that slowly and silently corrupts some of its content. Without some sort of detection scheme, the best that can be hoped for is "reallocated sectors" are blank areas on the disk, and that SMART notifications are set up so that the user is warned that the drive is beginning to die. If these warning mechanisms are not used or ignored, silently corrupted data may actually be backed up before the hard drive fails completely.

Enter ZFS, BTRFS, SNAPRAID, etc.:
These approaches use file check sums. When a check sum is calculated for a file, if a future calculation is done on the same file (in a scrub) and the checksum does not match, it's apparent that 1 or more bit errors have occurred. ZFS in a RAID 1 or 10 configuration replaces a corrupted file with a known good second file. BTRFS does something similar. SNAPRAID uses parity information and its' content file to recreate the uncorrupted original version of the file. The detection and (in some cases) correction of bit-rot is done in an operation called a "SCRUB". ((It's important to note that none of these detection/correction filesystems or schemes care about the low level details, or the mechanics of hard drives. They simply replace known corrupted files with verified clean versions.))

So why is detection and correction important? If you have a slowly failing hard drive, SMART should detect and "eventually" reallocate a corrupted sector. (Hard drives have a few extra sectors reserved for this purpose.) The problem is, when the data from the bad sector is copied to a reserved good sector, there's no guarantee that the pre-existing data in the bad sector is not corrupt.
Enter the "Scrub". When error detecting filesystems or SNAPRAID is used, the corrupt file is deleted (ZFS or BTRFS) and copied from a 2nd good file in a RAID1 "like" configuration or (SNAPRAID) recreated with parity data and a content file. In my experience, it is entirely possible that single bit-errors will be detected and corrected by a SCRUB operation before a bad sector is reallocated by SMART. This keeps data clean at the top level, on the primary server. When backing up, it's far better to backup known clean data that to take a chance that silently corrupted data is being replicated to a backup device.

But there is a cost:
In ZFS and BTRFS RAID1 type configurations, 50% of disk real-estate is lost. (ZFS works - tested.) It is claimed that BTRFS in RAID5 can recreate files from parity, but I have yet to actually verify bit-rot file recovery. (Eventually, I plan to test this.) In any case, 1 disk in 3 or more is lost to parity. SNAPRAID is similar and requires 1 disk (the largest of the disks) for parity, so bit-rot protection can be had for as little as 25% of a pool of protected disks. (SNAPRAID works - tested.)

All of the above require a bit of reading and setup of necessary household chores, with the exception of ZFS. ZFS, when it's setup in OMV, will run 1 scrub a month automatically. Doing the same with BTRFS would require command line scrub operations, but they can be setup in scheduled tasks and run from there. Most SNAPRAID housekeeping can be run manually in the GUI.

SNAPRAID has many features in addition to bit-rot detection and correction. As it is with most RAID configurations, SNAPRAID can recreate entire hard drives but it goes beyond that with file and folder restoration capabilities.
In the way of truly advanced features, ZFS and BTRFS can utilize "SNAPSHOTS" for retrieving past "versions" of a file as it existed in different points of time, or even restore an entire filesystem to an earlier point in time. (As an example, a filesystem can be rolled back to a time "before" a ransomware infection.)

It all boils down to whether or not you feel your data is worth protecting. If it's a bunch of video files that you don't care about, probably not. If it's a collection of irreplaceable family photos, you might consider bit-rot protection AND backup. Also, as a real consideration, is the reading and additional complexity involved.
_________________________________________________________

Here's the bottom line (again - my opinion):
Unless it's used with a gaming machine where disk I/O performance is the only consideration, I wouldn't use RAID0, *ever*. RAID0 is a ticking bomb. If either of your two disks fail, you lose it all. RAID0 is not appropriate for a NAS. If you don't want to spend the money on an extra drive for parity, I'd use the UnionFS plugin to pool your two drives together. In that way, if one disk fails, you'd still have the data on the 2nd disk. There's a performance hit but, for a home server, it shouldn't be a problem.

Again, these are mostly opinions. Others may have opinions and information more applicable to your use case.

Quote from HannesJo

If I understand it correctly, ZFS/BTRFS/SnapRAID will report when a data error has been detected and corrected. Maybe you have some experience in this area?

Yes, I've seen error detections with SNAPRAID. (Corrections, in SNAPRAID require a separate follow up operation.
In the SNAPRAID case, I set up a backup server that, as of day 1, had very old disks (around 5 years old), just to see what would happen. It's an anecdotal test to be sure, but I have seen error corrections without a drive failure. I have yet to see ZFS corrections but I started that array with new disks. (The idea is to avoid issues at the top level.)

Quote from HannesJo

It is hardly ever pointed out that every modern hard disk has its own protection mechanisms.

Again, going back to BER rates, error corrections schemes, etc.:
Since we are dealing with astronomically large numbers, without the built in error correction schemes modern day hard drives would be useless. *Remember 1 error in a million is far too many.* But, in the final analysis, the built in correction is still not enough. Cow filesystems and SNAPRAID operate on top of hardware as a last resort, verifying and maintaining clean data, while fixing errors that, with enough time, are inevitable.

Quote from HannesJo

As a result, I would like to get a feeling for how likely it is that in 10 years in my collection of 20,000 pictures, only one of them will actually be scrapped because there was no Bitrot protection.

in the basic concept, this is correct. In my understanding of the structure of some file types; a single bit error (bit-rot) might manifest, in a picture, as a color change in a pixel. If it's an ASCII file, a single letter may change. Such events, really, wouldn't be a big deal but it depends on where the error land. Again, this is a "silent" problem and time is not your friend. The reason I take it seriously is that I have files that go back to Windows 3.1 That's a long time.
There are many out there that have had files that they though were good, and were backed up religiously. When actually checked, they found that their files were nothing but gibberish, merely trash data with a file name. The condition of files on a hard drive is an unknown and remains unknown without something that tracks their initial state, and checks integrity from time to time.

I'm interested in bit-rot for two reasons.
1. Keeping data clean at the highest level (my primary server) so that backups to secondary devices are also clean.
2. Pre-warning before a hard drive failure. If I see misc error corrections I would; (1) Stop replication and check my backups, preserving back up files in a known good state. (2) Eyeball SMART data and start running long tests to see if a drive is getting weak. (3) Depending on the findings, put a drive on order.
The overall intent is keeping data clean while insuring longevity and survival.

Quote from HannesJo

Maybe there is a way to compare checksums between NAS and backup?

There are enterprise filesystems that support this, clustering file systems, maybe CephFS, but the implementation of them may not even be possible using the hardware of the typical home enthusiast. That says nothing about the learning curve involved. The details of setting up and operating these filesystems may not be easy; certainly not as easy as using the plugin's for ZFS or SNAPRAID, within OMV's GUI.

Quote from HannesJo

But you ignore the fact that if one of the hard disks fails, only that one disk is defective. So the probability of a single defective disk does not change at all. And my data is not irretrievably lost. I just can't read data from the RAID anymore.

I'd recommend reading up on RAID0. If one disk is dead, the data on both is gone. Data is "striped" across two disks, so nothing can be salvaged. That means, the weakest of the two disks will decide how long the array lasts.

Quote from HannesJo

A reliable picture of the risk of a data loss is hardly possible.

That's because storage technology is moving so fast, research on reliability and data loss doesn't exist for the latest tech. Along those lines, the backblaze study is the best data set and summary info available on the topic of consumer hard drive failure that I've found. Further, over the years, data center site admin's have developed known good strategies for insuring the continuity of customer data which is always (always) based in a good backup plan.
A solid backup plan has multiple copies of the data set, with (preferably) one copy off-site, and "versioning" which allows admin's to go back in time to previous data states.

Quote from HannesJo

Ticking time bomb vs. comprehensive and final security. That's what it sounds like when you read through many posts in many forums. I question that just because such tendentious statements are mainly good for convincing gullible people.

I have to say, I find this amusing. On the forum, I've found a few types of new users; the inexperienced type, that experienced forum members try to guide, and there are the hardheaded type that learn things the hard way. I'm fine with both because they'll be living with the consequences of their choices. Again, we're talking about matters of opinion here, but I have enough experience to where I have a few notions of what works and what doesn't.

When it comes to RAID, there are people who have been "lucky" and never had a failure. Maybe it's because they update their hardware and/or drives before a drive failure. There's numerous factors involved. And there are people who have had RAID failures, many without back up. You'll find those horror stories a-plenty if you search the forum using the right terms. Usually, they were RAID5 victims, using a RAID array without really understanding what it is, without setting up SMART notifications, etc. RAID0 is another matter altogether, it's in a class of its own.

I call RAID0 the "insane array". Can you use it? Sure. One can take a great many risks with a solid backup plan, but that still won't change the fact that RAID0 is not suited for servers and (in my opinion) is an unnecessary risk. Nearly anyone on this forum, with experience, would tell you that. It has nothing to do with gullible users.

Quote from HannesJo

I think you misunderstood me in my basic criticism of reasoning.

Maybe - it wouldn't be the first time.
_______________________________

It should be noted that many OMV users do not have backup, and I believe it's higher than 50% . While this is your thread, others will read it. Some of what is written is intended for them, in the hope that readers won't take unnecessary risks AND will maintain solid back up so they don't end up back here. Some come back anyway, with dead or dying drives and no backup. Here's an example. At this time, it's at 10 forum pages and still going.
_______________________________

If you go the ZFS route, for bit-rot, use a "zmirror" which is RAID1 and take a look at setting up automated SNAPSHOT's. It's a great feature of the filesystem. zfs-auto-snapshot is really nothing more than shell scripts and cron jobs but that's a good thing. It upgrades well - there are no dependencies so there's little to nothing to break.

BTRFS can do much of the same, but I don't know the in's and out's. I'm waiting for it to become a bit more stable before diving into "RAID1 like" mirror implementations for bit-rot protection. ((Some say it will scrub bit-rot in RAID5 but I'd have to thoroughly test that before I believe it.))