ZFS (allgemein, ich weiss nicht, welche Features FreeNAS davon nutzt) erstellt, wie auch BTRFS, Prüfsummen aller geschriebenen Dateien. Mit Hilfe dieser Prüfsummen überprüft es sowohl beim Zugriff auf die Dateien sowie regelmäßig (Scrubbing) die Korrektheit. Hat man genau bei dieser Aktion einen Ram-Defekt, welcher das System nicht zum Absturz bringt, werden mind. alle Daten auf der HDD als Defekt markiert. Hat man dazu noch eine Redundanz (z.B. so ähnlich wie bei RAID 5), dann versucht ZFS beim Scrubbing, die angeblich defekten Daten auf der HDD zu korrigieren. Mit defektem Ram ist das nicht so prickelnd und kann die Daten zerstören.
Ein RAID5 prüft und korrigiert nur beim Lesen und nicht automatisch bei Inaktivität des NAS.
Daher wird von vielen Powerusern ein System mit ECC-Ram empfolen, womit man auch eine passende CPU/Mainboard benötigt.
ZFS kann zusätzlich auch so schöne Dinge wie Datendeduplikation. Damit werden identische Daten nur einmal auf der HDD gespeichert. Wobei es nicht um komplette Dateien geht sondern um identische Datenblöcke. Diese Blöcke muss aber natürlich die CPU identifizieren (lassen wir einen potentielle Ram-Fehler dabei mal außen vor). Dafür braucht man Rechenleistung und einen schnellen Zwischenspeicher, womit das NAS eine vergleichsweise schnelle CPU und viel Ram benötigt (irgendwo habe ich mal was von 1GB Ram je 1TB Speicherplatz gelesen). Außerdem müssen diese Prüfsummen für den schnellen Vergleich im Ram vorhanden sein, womit das NAS entweder 24/7 laufen sollte oder nach dem PowerOff erst einmal den Cache mit den Hashes einlesen muss.
Soweit meine Erkenntnis, als ich das vor ein paar Jahren mal in Erwägung gezogen habe. Ich habe mich dann ohne viel ECC-Ram für die Light-Variante entschieden und nutze nur die Prüfsummen von BTRFS. Falls mein Linux nicht falsch konfiguriert ist, läuft dort kein automatisches Scrubbing. Wobei es auch dann nur Fehler melden könnte, das System läuft ohne RAID, da ich in den letzten 20 Jahre zu wenige HDD-Ausfälle hatte und auch schon ein nicht wieder herstellbares RAID (in einer angeblich professionellen SAN) erlebt habe.
Ich verwende keine spezielle NAS-Software. Ich benötige weder eine Cloud noch einen Medienserver. Das NAS liefert einfach nur Ordnerfreigaben (mit Lese- oder Schreibrechten), kann das Backup vom anderen NAS erstellen und sollte ursprünglich ein iSCSI Laufwerk zur Verfügung stellen. Weitere Wünsche, wie z.B. VMs zu hosten, habe ich derzeit noch zurück gestellt. Dafür fehlen mir die lang laufenden VMs und für ein paar Tests kann das mein PC mind. genauso gut.
Auf dem Haupt-NAS läuft mittlerweile wieder ein Win 10 Home, auf dem Backup-NAS derzeit noch ein Linux Mint 18.3.
Ich wollte damals mit Linux einige Dinge nutzen, die Windows im Client nicht mitbringt (insb. BTRFS und iSCSI), und das bei erträumten weniger Updates und/oder Pflegeaufwand. Mittlerweile macht Linux Mint 18 bei mir aber mehr Probleme wie es nützt. Das lässt sich sicherlich alles mit sehr viel Zeitaufwand konfigurieren.
Das Problem ist vor allem, dass es für Mint (und auch für das zu Grunde liegende Ubuntu), ja nach Installationszeitpunkt nur 3-4 Jahre Security-Support gibt. Dies ist für Mint 18.3 im April 21 beendet, mit Installation Anfang 2018 sind das dann für mich gut 3 Jahre. Der Umstieg auf Mint 19.X scheint nach Beschreibungen im Netz nicht trivial zu sein, was bei all den manuellen Konfiguarationen, die ich machen musste, auch kein Wunder ist.
Auf dem neuen Haupt-NAS lief anfänglich Mint 19.3 (in der irrigen Hoffnung, die allermeisten Konfigurationen identish/ählich zu 18.3 durchführen zu müssen) und es hat mir zweimal fast Daten vernichtet. Mir ist es nicht gelungen, das Suspend to Ram/Disk vollständig zu deaktivieren. Ich hatte ein VeraCrypt Image von einer Freigabe gemountet und länger nicht darauf zugegriffen. Plötzlich war das NAS aus und lies sich nur noch mit eine Griff zum Netzschalter reaktivieren (Tastatur/Maus/Monitor waren nicht angeschlossen). M.M.n. hatte ich alle Energiesparoptionen, die zum Ausschalten des PCs führen könnten, deaktiviert.
Jedenfalls war ich froh, dass ich dort NTFS und kein BTRFS genutzt hatte. Windows gebootet und alles lief wie gewünscht. Jetzt gibt es zwar kein iSCSI (habe ich wegen viel zu hohem Konfigaufwand im Vergleich zum QNap auf Mint 18.3 mittlerweile auch aufgegeben) und die Datenprüfung muss ich halt wieder über meine Tools erledigen. Ob ich WinBTRFS trauen soll, weiss ich noch nicht.
Als Linux würde ich persönlich nur noch Distributionen testen, die einen langen Supprt bieten, z.B. CentOS. Das ganze muss dann "nur" noch auf der vorhandenen HW laufen (Mint 18.3 hat meine 10 GBase-T Karte z.B. nicht erkannt).
Nicht "und" sondern "oder". Entweder OMV oder Linux oder Windows (falls OMV nicht in einer VM laufen soll). Das ist halt die Frage worauf Du Wert legst. Cloud+Medienserver zuerst zum Spielen und sich danach für ein Speicherkonzept entscheiden. Oder erst das Speicherkonzept und damit herum spielen (z.B. DrivePool auf Windows) und danach die Services hinzu fügen.
