Beiträge von gea

Zitat von wtuppa

ist auch der sichere, da dann echt Platz reserviert ist. Mit Quotas kann man nur maximum für User angeben, allerdings kann jemand anderer den Platz vollschmieren.

Darum ja ZFS als Dateisystem.
Damit kann man nicht nur per user sondern per Dateisystem (z.B. das Dateisystem für TM) eine Quota setzen die nicht umgangen werden kann sowie darüberhinaus eine Reservation um einen bestimmten Platz des gesamten Daten-Pools für ein Dateisystem zu garantieren.

Im Gegensatz zu festen Partitionen kann man das jederzeit flexibel einstellen.

Wenn man netatalk (end of life) für TM nutzt, kann man mit dem parameter vol size limit arbeiten

vol size limit = size in MiB (V)Useful for Time Machine: limits the reported volume size, thus preventing Time Machine from using the whole real disk space for backup. Example: "vol size limit = 1000" would limit the reported disk space to 1 GB., http://netatalk.sourceforge.net/3.1/htmldocs/afp.conf.5.html

Aktuelles OSX will aber nicht mehr netatalk sondern SMB.
Da kann man dann mit ZFS als Dateisystem und Quotas arbeiten um den Platz zu begrenzen (bzw mit reservation um eine bestimmte Kapazität zu garantieren).

Statt Festplatten oder Container zu verschlüsseln kann man auch Dateisysteme verschlüsseln sofern man als Dateisystem ZFS wählt. Hier kann man dann je Dateisystem ein anderes Passwort wählen und man kann das verschlüsselte Dateisystem "raw" per ZFS Replikation sichern, auch auf "unsichere" Datenorte oder über unsichere Netze. Die Übertragung und das Ziel ist dann verschlüsselt. Zum Entschlüsseln brauchts den Schlüssel des Quell Dateisystems.

Für kleinere Sachen kann man auch einen ZFS Pool auf eine oder mehreren Dateien anlegen (basic oder mirror) und die Dateien per Copy sichern. Bei Mirror hat man sogar Redundanz wenn z.B. der USB Stick Fehler hat.

Wenn bei ZFS und einem Speicherfehler Müll geschrieben wird, so wird das beim Lesen aufgrund der Prüfsummen erkannt und mit hoher Wahrscheinlichkeit passiert nicht mehr als dass eine Datei als Defekt markiert wird, eventuell aus dem Raid repariert wird. Die Platte oder der Pool wird wegen "too many errors" offline gestellt. Tools wie chkdsk gibt es nicht weil ZFS per Design keine unentdeckten Fehler haben sollte und auch bei einem Crash beim Schreiben wegen Copy On Write kein korruptes Dateisystem hinterläßt.

Worst case ist ein Strukturfehler. Wegen der doppelten Metadaten sehr unwahrscheinlich aber im schlimmsten Fall ist der Pool nicht mehr lesbar.

Wenn bei ext4 und einem Speicherfehler Müll geschrieben wird, so bleibt das unerkannt da beim Lesen mangels Prüfsummen nichts verifiziert werden kann. Stützt das System beim Schreiben ab, gibt es eventuell ein korruptes Dateisystem. Mit fschck/chkdsk kann man jetzt überprüfen ob die Struktur fehlerfrei ist. Mangels Prüfsummen ist das aber sehr oberflächlich. Eine echte Fehlererkennung auf Datenebene ist nicht möglich.

Worst case ist ein Strukturfehler. Hatte ich mal bei meinem Mailserver unter ntfs. Nach stundenlangem Reparieren war "Buchstabensalat" das Ergebnis.

Auch ohne ECC ist ZFS einem ext oder ntfs Dateisystem weit überlegen was Datensicherheit betrifft. Beide können durch RAM Fehler hops gehen und bei beiden sollte man für den Disasterfall ein Backup haben.

Die Mär vom ZFS Totreparieren ist genau das, eine Mär.

Es ist selten, dass mich etwas so richtig begeistert und ich mich frage, warum ich das nicht schon immer so gemacht habe und warum die Alternativen alle so unheimlich umständlich sind.

Dieses Gefühl beschleicht mich mich seit ich minIO teste. Man kann es als Profi-Alternative für Nextcloud sehen. Nicht soviele unterstützte Clients und Extras dafür sensationell schnell und skaliert bis Zetabytes wenn man es als Cluster betreibt. Außerdem ist minIO als Applikation eine einzige Datei, ohne die sonst üblichen und üblen Abhängigkeiten zum OS oder anderen Programmen. Man installiert das Programm und aktiviert S3 Sharing einfach zusätzlich zu SMB das man lokal im LAN nutzt und hat damit Versionierung via ZFS Snaps und [definition=40,0]Windows[/definition] vorherige Version oder Verschlüssellung via ZFS.

Ich unterstütze es seit gestern in napp-it. Installation und Screenshot, siehe https://forums.servethehome.co…-minio.27524/#post-257208

Mal ein weiteres Info

OmniOS hat minIO ins Extra Repo aufgenommen. (ja, minIO geht auch mit OMV)
Damit läßt sich OmniOS (Solaris Fork, speziaisiert auf ZFS Server) mit ein paar Klicks ganz einfach und schnell zu einem [definition=35,0]Amazon[/definition] S3 kompatiblen Server ergänzen.

Interessant ist das als Inhouse/Internet Backup Server für Clients wie Duplicati, rclone oder Veeam oder dem minIO beiliegenden Webclient.

Setup und Betrieb:
https://forums.servethehome.co…lient-server-minio.27524/

OmniOS 151032 stable ist da
Das ist das größte und umfassendste Update für Open-ZFS und OmniOS das jemals veröffentlicht wurde.
download: Downloads

Release notes
omnios-build/ReleaseNotes.md at r151032 · omniosorg/omnios-build · GitHub

Update
http://www.napp-it.org/doc/downloads...napp-it_os.pdf

New Open-ZFS features (sind auch in ZFS on Linux ab v.0.8):
- native ZFS encryption
- raw zfs send of locked and encrypted filesystems
- sequential/sorted resilver (can massively reduce resilver/scrub time
- manual and auto trim for the SSDs/NVMes in a pool
- Allocation classes for metadata, dedup and small io (mixed pool from disk/SSD/NVMe)
see https://www.napp-it.org/doc/downloads/special-vdev.pdf
a warning at this point: a zpool remove of a special vdev with a different ashift than the pool crashes Illumos/ZoL
- force ashift on zpool create/add

OmniOS related
-updated NVMe driver (with basic support for NVMe/U.2 hotplug)
-updates for newer hardware
-installer supports UEFI boot

- SMB 3.02 (kernelbased SMB) with many new features
see Pull Requests · illumos/illumos-gate · GitHub
- improvement for LX/ Linux zones, newer Linux distributions
- improvements for Bhyve
- improvements to the Enlightened Hyper-V drivers for running under Hyper-V or Microsoft Azure.

Napp-it 19.dev/19.h2.x supports the new features

neues Open-ZFS Feature: Allocation Classes

Diskbasierte Datenspeicher sind billig und langsam. Selbst ein rambasierter Schreib/Lesecache wie bei ZFS oder eine SSD als Lesechache hilft nur bedingt und nicht beim ersten Zugriff. Hinzu kommt, dass sicheres und schnelles syncrones Schreiben auf mechanischen Platten übel langsam ist und auf billigen SSD nicht sicher.

Ein Ausweg war bisher Tiering bei dem man einzelne Dateien oder Ordner auf ein schnelleres SSD Array verschiebt. Neben dem Verwaltungsaufwand bringt das aber auch selbst Performanceprobleme bei stark belasteten Servern und ist nicht sonderlich flexibel.

Bei Open-ZFS kommt jetzt ein neuer Ansatz hinzu: Daten-Pools die aus billigen Platten bestehen (Kapazität), ergänzt durch bezahlbare schnelle SSD/NVMe für Performance und hohe iops und dazu eine kleine ultraschnelle, teure NVMe Slog für sicheres syncrones Schreiben. Das Besondere dabei ist, dass neben den zeitkritischen Metadaten einzelne Performance-sensitive Dateisysteme einzeln ausgewählt werden können, die auf dem schnellen Speicherbereich landen.

Gibt quasi die eierlegende Wollmichsau im Storagebereich wenn es um Bezahlbarkeit geht. Kapazität zu geringsten Kosten, bezahlbare hohe bis extrem hohe Performance für Anwendungen die das brauchen und dazu kein Datenverlust bei einem Absturz während eines Schreibvorgangs - neben all dem was ZFS sonst ausmacht wie crashsicheres Dateisystem, Ransomware sichere Snapshots oder Prüfsummen auf Daten/Metadaten.

Ich habe dazu mal eine Serie von Benchmarks gemacht, die das veranschaulichen.
http://napp-it.org/doc/downloads/special-vdev.pdf

Zitat von Sc0rp

Was mich aber am Meisten am ZFS-Zx stört, ist, das immer nur ein Member des Verbundes oder Pools angesprochen wird - d.h. ZFS-Zx skaliert nicht wie RAID mit mehr Membern - da muss man dann für die Endperformance wirklich Cachen wie irre ...

Sc0rp

EDIT: ps: Sorry für "totally OT" ...

Was verstehst du unter "Member", einzelne Platten oder vdevs (Raid-Arrays)?

ZFS skaliert die sequentielle Performance mit der Anzahl der Datenplatten wie bei Raid 5/6 und die iops mit der Anzahl der vdevs. Zwei vdevs z.B. 2 x Z2 haben die doppelten iops wie ein vdev. Ist wie bei Raid-6 zu Raid-60. Auch da verdoppeln sich die iops In beiden Fällen verdoppelt sich auch die sequentielle Performance.

Vdevs bei ZFS werden als Raid-0 zusammengeschaltet. Da die Anzahl der vdevs nicht wie bei Raid-60 auf zwei beschränkt ist, kann ZFS weiter skalieren. Ein Raid-600000 gibt es nicht, einen ZFS Pool mit 6 vdevs häufig.

ps
Ich finde nicht, dass Storage Grundlagen für ein NAS Selbstbau OT sind.

Losgelöst von dem Wunsch der Linux Entwickler im Kernel nur GPL Software zu haben, kann man das recht entspannt sehen. Oracle ZFS v45 ist closed source und damit nicht frei verfügbar. Open-ZFS auf Basis von OpenSolaris ZFS v28 ist OpenSource und frei nutzbar und erweiterbar. Und dank dem Dach von Open-ZFS wird das auch plattformübergreifend sehr kompatibel gehalten was neuere Features angeht. Bei den Open-ZFS Entwicklungen hat auch noch niemand ZFS Features als closed source gebracht, auch wenn das siehe Oracle möglich wäre. Das würde dann aber auch nicht in Open-ZFS unter der CDDL Lizenz erscheinen sondern wäre was Hersteller spezifisches.

Das war schonmal anders. Da ging es aber darum, dass NetApp ZFS verhindern wollte weil sie darin zuviel Ähnlichkeit wenn nicht gar überlegende Konkurrenz zu ihrem Dateisystem Wafl sahen. Das hat wohl auch Apple vor 10 Jahren davon abgehalten ZFS in OSX voll zu integrieren nachdem das eine Zeitlang bei OSX Server dabei war. Dieser Rechtsstreit ist aber lange abgeschlossen.

Die einzige Frage momentan ist doch wohl nur ob wie bei Ubuntu ZFS Teil einer Linux Distribution ist oder ob das separat nachinstalliert werden muss.

zum Ram bei ZFS
Ein ZFS Filer mit 4GB ist schon ganz ok sofern da nicht viele Extra Dienste laufen und ein besonders "fettes" Managenment Tool wie FeeNAS dazu kommt. Dann würde ich erst mit 8GB anfangen. Wenn man bei 4GB die Hälfte für das 64bit OS abzieht, bleiben immer noch mehrere Hundert KB als Schreibcache (Open-ZFS default ist 10% RAM, max 4GB) und mehr als 1 GB als Lesecache. Damit sollte man bei ZFS Z1 auch 1Gb Netzwerkperformance beim Lesen/Schreiben - zumindest bei eher sequentiellen Workloads und nur einem oder wenigen Nutzern und sofern man "sicheres sync" Schreiben nicht aktiviert - erhalten. Bei mehreren Nutzern kann das schnell absinken, da ZFS seine Daten über das Raid verteilt und dann weniger die sequentielle Poolperformance (n x Datendisks) limitiert sondern die iops für wahlfreien Zugriff. Und ein Raid wie ein Z1 hat da nunmal nur soviel iops wie eine einzelne Platte also ca 100. Dann wird der Lesecache extrem wichtig. Ein ZFS System mit viel RAM kann dann manchmal über 80% aller Lesevorgänge aus dem RAM bedienen. Platte ist dann egal.

Wenn man aber sync write aktiviert um den Schreibcache abzusichern, geht das sicher auf unter 30MB/s zurück. Wenn man den Speicher wirklich knapp hält also z.B. nur 1-2 GB RAM hat, sieht das nochmal anders aus. Wenn man z.B. den Lesecache bei ZFS deaktiviert um das zu simulieren so hat man bei SSD immer noch Performance, eine langsame Platte kann dann aber auf wenige MB/s einbrechen. Bei einer WD green hatte ich da lediglich 3 MB/s, https://forums.servethehome.co…led-and-slow-disks.12170/. Ich habe auch mehrere Testreihen mit unterschiedlich RAM gemacht und da sieht man, dass die Performance mit RAM deutlich zunimmt oder dass man sicheres Sync Schreiben auch schnell bekommt oder wie ZFS sich generell bei random vs sequentiellen Lasten verhält, https://napp-it.org/doc/downlo…_slog_pool_performane.pdf Kapitel 5.8

Zitat von Sc0rp

2) Lizenzprobleme:
- ZFS ist ein tolles Dateisystem, aber leider nicht "wirklich frei", die Lizenzproblematik ist nicht abschließen geklärt - auch ZoL ist davon betroffen
- ich persönlich warte auf BTRFS, das m.M.n. schon viel zu lange ...

Sc0rp

ZFS ist seit OpenSolaris OpenSource, die Quellen sind offen, alle entwickeln darauf tolle
Sachen. Aktuell wurde von Datto aus dem ZoL Lager Native ZFS Verschlüssellung zu
Open-ZFS hinzugefügt. Datto setzte gerade wegen der Lizenz Problematik dabei auf die Solaris Lizenz - zumal in Illumos die Verschlüssellung bereits zu 90% fertig war.

Das Problem ist nicht ZFS oder die ZFS Lizenz sondern die GPL. ZFS steht unter einer Lizenz die zwar die freie Nutzung und die Weiterentwicklung erlaubt aber die Rechte der ursprünglichrn Lizenzgeber beibehält. Deshalb kann die ZFS Lizenz selbst von Oracle nicht mehr geändert werden. Oracle hat eben nur "fast" alle Rechte. Oracle ist zwar die treibende Kraft hinter btrfs, Oracle "gehört" ZFS und Oracle hat jetzt eher eine Linux Präferenz. Dennoch bleibt die ZFS Lizenz wie sie ist. Original ZFS von Oracle ist zwar immer noch am schnellsten und hat die meisten Features. Open-ZFS holt aber gehörig auf, nicht zuletzt wegen der Unterstützung aus dem Linux Lager.

Das "Linux Problem" besteht nun darin, dass alles was zum eigentlichen Linux gehören soll, den GPL Lizenzbedingungen folgen muss, was ZFS nicht kann. Ist aber eh akademisch seit ZFS überall dabei ist oder zu haben ist. Btrfs ist heute bei wichtigen Featuters wie sicheres Schreiben oder höheren Raid Levels noch nicht da, wo ZFS bereits vor 10 Jahren war. Es gibt zwar Feautures die btrfs voraus hat, die sind aber bei "Crical Use" eher weniger wichtig und ZFS hat die auch bald wie "Erweitern eines einzelnen Raid-Arrays um eine einzelne Platte". ZFS ist auch nicht auf Linux beschränkt. Neben den Unixen Free-BSD, OSX, Solarish und Linux ist sogar für [definition=40,0]Windows[/definition] ein Port in Arbeit.

Für btrfs wird es diese plattformunabhängigkeit nie geben. Ob es featuremäßig gleichziehen kann ist mehr als fraglich. ZFS entwickelt sich dazu schneller weiter als btrfs. Unmöglich das aufzuholen nur um der "reinen Linux Lehre" zu genügen..

kleine Ergänzung zu den Aussagen zu ZFS

A: Datenintegrität in Verbindung mit ECC-Ram unschlagbar
E: ZFS bringt die Sicherheitsmerkmale Crashsicherheit (CopyOnWrite), Snaps und Prüfsummen. ECC ist ein weiteres Sicherheitsmerkmal, arbeitet aber unabhängig von ZFS, schließt bei ZFS allenfalls die letzte größere Sicherheitslücke.

A: Sehr gute Performance
E: ZFS ist eigentlich langsamer als "ältere" Dateisysteme. Die Extra Sicherheit mit CopyOnWrite und Prüfsummen kostet Performance. Ausgleichen, ja sogar "überkompensieren" kann man das mit RAM. Mit viel RAM als Read/ Write Cache kann ZFS sehr viel schneller sein als ältere Dateisysteme. Mit wenig RAM ist ZFS langsamer als z.B. ext4 oder ntfs.

A: Es drehen immer alle Platten bei einem Datenzugriff
E: Das gilt für jedes Realtime Raid. Hat nichts mit ZFS zu tun.
Lediglich z.B. bei Raid on Demand können alle Platten bis auf die aktive schlafen. Da machen lediglich eine Art Backup auf Anforderung mit den Prinzipien eines Raid.

A: Im Gegensatz zu anderen Dateisystemen wird mehr Ram benötigt
E: Ein Dateisystem braucht im Prinzip kein RAM. Oracle mit Original-ZFS verlangt 2 GB RAM als Minimum. Das ist das was jedes aktuelle 64bit OS benötigt und Oracle verlangt für ZFS auch bei PetaByte Pools nicht meht und die müssen das ja wissen mit ZFS.

Man kann allenfalls sagen, dass die Sicherheitsmerkmale CopyOnWrite und Prüfsummen mehr Fragmentation und mehr Daten bedeuten. ZFS ist damit prinzipiell langasamer als Dateisysteme ohne. Der Ausgleich den Sun bei ZFS eingebaut hat ist ein überragender rambasierter Schreib/Lesecache. Dafür brauchts RAM. Würde man extrem schnelle Platten wie Intel Optane benutzen, wäre der Performancevorteil mit mehr RAM gering.

A: SMB-Datenübertragung für meine Verhältnisse Grottenschlecht!!
E: Hat nichts mit ZFS zu tun. Liegt allenfalls am SMB Server SAMBA oder dessen Konfiguration. Der kernelbasierte multithreaded SMB Server ist da meist etwas schneller, den gibts aber nur bei Solarish als Alternative zu SAMBA.

A: Pool Erweiterbarkeit
E; ZFS kann man durch Austausch aller Platten eines einzelnen Raid Arrays (vdev) oder durch anfügen weiterer Raid Arrays an den Pool erweitern. Ein einzelnes Raid-Z Array kann man noch nicht erweitern (ist in Arbeit, vorraussichtlich verfügbar erst nächstes Jahr). Ein vdev entfernen ist ohne Einschränkung bei Solaris ZFS möglich, bei Open-ZFS noch beschränkt auf Mirror.

Ein ZFS Mirror ist auch ein reines Raid.
Der Unterschied zu einem bisherigen Mirror

Bei einem bisherigen Mirror wird erst die erste Platte aktualisiert, dann die zweite Platten. Ein Crash beim Schreiben führt dazu, dass eine Platte korrupte Daten hat. Wird beim Lesen alternativ von beiden Platten gelesen, ist es Zufall ob korrekte oder korrupte Daten gelesen werden. Mangels Prüfsummen auf den Daten kann das im Nachhinein nicht entschieden werden. Ein Hardware-Raid mit Cache und BBU/Flash Sicherung kann helfen. Das Problem nennt sich write hole Problem.

ZFS macht das anders. Wegen CopyOnWrite werden vorhandene Daten nicht verändert, sondern Datenblöcke komplett neu geschrieben. Erst wenn Daten sicher auf beiden Platten gelandet sind, werden Metadaten verändert und der Schreibvorgang ist abgeschlossen. Bei einem Crash dazwischen wird die komplette Aktion verworfen und das Dateisystem und das Raid bleiben valide.

Doppelte Metadatem und Prüfsummen auf Daten und Metadaten erlauben es ZFS Fehler, die dennoch auftreten können sicher zu erkennen und aus der Redundanz on the fly zu reparieren. (Selbstheilendes Dateisystem)

zu ECC

Schönes Beispiel warum man ECC haben sollte und was passiert wenn Speicherfehler ohne ECC unter ZFS auftreten. (Bei ZFS erfährt man wenigstens wenn Dateien kaputt gehen)

https://forums.servethehome.co…see-affected-files.24990/

Zitat von Sc0rp

Und was ist das Fazit?

ECC RAM verbessert eindeutig die Datensicherheit!
Braucht man nicht?

Neue Dateisysteme verbessern eindeutig die Datensicherheit!
Braucht man nicht?

Raid verbessert eindeutig die Datensicherheit?
Braucht man nicht, rsync reicht.

Raid-6/Z2/Z3 verbessert eindeutig die Datensicherheit vs Raid-5
Braucht man nicht?

Echt-Datenprüfsummen z.B. auf einen 1M Datenblock
und Metadaten verbessern die Datensicherheit.
Braucht man nicht?

Selbst at home ist die einzige Argumentation dagegen
ein paar gesparte Euro. Auch das Komplexitätsargument zieht
nicht. ZFS Raid ist einfacher zu verstehen als manch anderes Raid.
Wenn jemand da Fragen hat oder Hilfe braucht, dem kann ich gerne helfen.

Als Dateisystem werkelt es eh einfach im Hintergrund.

Da sind wir aber weit auseinander.

Zitat von Zeze21

Also ich hab jetzt mehrere Jahre mein Raid 5 im Betrieb und noch nie musste ich einen Rebuild machen.

So ist das halt mit der Statistik.
Rauchen ist schädlich. Trotzdem wurde Helmut Schmidt sehr alt. Man sollte sich aber das nicht als Vorbild nehmen. Nicht jeder ist Gustav Gans.

Es gibt Konfigurationen, die nach 10 Jahren ziemlich sicher zu einem Datenverlust führen, selbst wenn man das nicht immer sofort merkt, z.B. weil man ohne Datenprüfsummen das gar nicht so einfach merkt. Erst wenn man z.B. ein Bild öffnetund die Hälfte schwarz ist sieht man das. Wer ZFS nutzt, erkennt sowas wenn es Checksum errors beim Zugriff oder scrub gibt. Das erkennt nur ZFS, das Raid oder die Festplatte nicht. Die betroffene Datei ist definitiv korrupt.

Es gibt andere Konfigurationen bei denen das Risiko nahe Null ist und das obwohl heutezutage RAM und Kapazität immens zunehmen. Ransomware droht und ein Voll-Backup bei entsprechender Kapazität 2 Wochen dauern kann. Dazu beigetragen hat Sun mit Solaris und ZFS vor 15 Jahren mit der Entwicklungen von ZFS mit Copy On Write, Snaps und Prüfsummen auf Daten und Metadaten die ja auch in Linux btrfs und [definition=40,0]Windows[/definition] ReFS eingeflossen sind.

Diese neuen Konzepte nicht zu nutzen weil es früher ja auch anders ging ist wie Auto ohne ABS und ESP zu kaufen "weil es früher ja auch ohne ging und ich nie einen Unfall hatte".

Es ist ja nicht so, dass man eine NetApp für 100000 Euro kaufen müsste um dieses Sicherheitsniveau zu haben, ZFS ist OpenSource. Man muss es einfach nutzen. Gottseidank hatte die Klage von NetApp gegen ZFS vor 10 Jahren keinen Erfolg und Sun hat OpenSolaris mit ZFS als OpenSource veröffentlicht.

Ich hatte früher auch mal ein Raid-5 auf meinem [definition=40,0]Windows[/definition] Mailserver. War so der beste Raidcontroller damals mit Cache und BBU. Lief langer gut. Irgendwann gab es Zugriffsprobleme auf einzelne Mails. If habe dann ein chkdsk gestartet. Lief einen Tag und das Ergebnis erinnerte an Rührei. War vor über 10 Jahren. Ich habe mir dann ZFS angesehen (als Apple sich das überlegte) und bin gewechselt und habe das nie bereut.

Zwischenzeitlich habe ich mit napp-it meine eigene ZFS Appliance auf Solarish und beschäftige mich auch beruflich intensiv mit Storage (weniger at home, eher Petabyte und Cluster).

Wenn es sich um "sehr gute" 5 x 3TB Platten handelt (1 Fehler pro 10^15) so ist die Wahrscheinlichkeit eines Raid Verlusts bei 12% lt http://www.raid-failure.com/raid5-failure.aspx

Wenn man also 100 mal das Raid-5 neu aufbaut, kann in 12 Fällen das Array verloren gehen. Je nach Blickwinkel ist das "doch sehr unwahrscheinlich" bis Oh mein Gott - ist dann wirklich alles weg.

Ein Raid-5 kann man nicht in ein ZFS Softwareraid wandeln. Wenn es sich jetzt um [definition=40,0]Windows[/definition] handelt gibt es derzeit noch gar keine Option mit ZFS. Da müsste man entweder auf ein Unix NAS wechseln (Solarish wo ZFS herkommt oder Free-BSD wo es das seit geraumer Zeit gibt) oder Linux bei dem ZFS sich auch immer mehr durchsetzt, ohne bisher die Reife von Solarish oder Free-BSD zu haben.

Man könnte zwar unter ZFS ein Raid-5 betreiben, würde sich damit aber vieler Vorteile von ZFS berauben und hätte weiter alle Nachteile von Raid-5.

ZFS für [definition=40,0]Windows[/definition] ist noch nicht fertig,
https://www.pro-linux.de/news/…indows-wird-stabiler.html

Die wichtigsten ZFS Neuerungen wie crashsicheres Dateisystem (CopyOnWrite), Snapshots und Prüfsummen - zumindest auf Metadaten hat Microsoft ja in ReFS eingebaut.

Zu ECC
Speicherfehler steigen mit der RAM-Nutzung. Das sind aber nicht nur User oder laufende Prozesse. Jedes neuere OS, nicht nur wie früher Solaris mit ZFS nutzen freien RAM als Cache. RAM Fehler steigen damit proportional mit der Speichermenge. Und da ein heutiges Basis-NAS mehr RAM hat als ein Profisystem vor 5 Jahren wird dieser Aspekt auch da immer wichtiger. Als ein Server noch 500 MB RAM hatte war ECC tatsächlich weniger ein Problem, https://www.heise.de/newsticke…er-angenommen-828883.html

Raid-5
Das Problem bei Raid-5 ist nicht die Geschwindigkeit sondern die Fehlerrate bei großen Platten. Fällt eine Platte aus, darf beim Rebuild kein weitere Fehler auftreten, sonst bricht der Rebuild ab. Bei ZFS Raid Z1 wäre nur die betroffene Datei verloren.

Hat man z.B. drei Platten a 8 TB im Raid-5 mit einer Fehlerrate von 1 Fehler pro 10^15 gelesenen Bits so liegt die Wahrscheinlichkeit eines erfolgreichen Rebuilds bei nur gut 80%. Man kann nun bei seinen Platten nach der Erfolgsrate schauen. http://www.raid-failure.com/raid5-failure.aspx

Als Platten noch im Gigabyte Bereich lagen war Raid-5 ok. Heute würde ich das mit multi-TB Platten grundsätzlich nicht mehr machen. Eher Raid-6/Z2/Z3 oder gar kein Echtzeit Raid wie Unraid bei einem Home Mediaserver etc.

Muss jeder natürlich selbst abschätzen. Jedes Setup ist ein Kompromiss.

Im Prinzip ist es wie beim Autofahren.
Man kann sagen ich fahr eh langsam und Sicherheit auf Stand eines älteren Autos (nur Sicherheitsgurt) reicht. Oder man kann sagen, ich möchte den Sicherheitsstandard nach Stand der Technik mit besserer passiver Sicherheit, ABS und ESP.

Bei Storage ist es genauso.
Wenn man mehr Speicher hat, treten häufiger Speicherfehler auf. Kann sein das macht nix, kann sein der Rechner stürzt ab, kann sein Daten werden verfälscht. Kann man was dagegen machen, nennt sich ECC Speicher. Ist vereinfacht sowas wie Raid-5 bei Festplatten.

Eine Schreibaktion besteht immer aus mehreren Teilen. Daten + Metadaten oder Raid Stripeset um Stripeset. Das geht nacheinander auf Platte oder die Platten. Stürzt der Rechner ab, ist das unvollständig geschehen mit der Folge eines korrupten Dateisystems oder Raid. Kann man was dagegen machen mit Copy on Write Dateisystemen und Software Raid, http://www.raid-recovery-guide.com/raid5-write-hole.aspx.

Bei einem traditionellen Raid-5 fällt eine Platte aus. Man ersetzt die und started den Rebuild. Tritt auf einer weiteren Platte auch nur ein nicht behebbarer Fehler (bei multi-TB Platten relativ wahrscheinlich) auf, ist das Raid verloren. Bei ZFS z.B. nur eine Datei.

Daten verändern sich auf Platte mit einer statistischen Häufigkeit. Nennt sich silent errors oder neudeutsch Datenrost. Neuere Dateisysteme wie ZFS mit Daten-Prüfsummen können sowas erkennen und reparieren.

Ab und an löscht oder ändert man aus Versehen etwas oder ein Trojaner verschlüsselt die Daten. Passierte vorletzten Montag abend nachdem wichtige Daten geändert wurden. Man bräuchte ein Backup vom Montag16:00, hat aber nur ein sehr altes. Dagegen helfen ZFS readonly Snaps, z.B. ein Snap je Stunde für die letzten 14 Tage, ein Snap je Tag für die letzten 60 Tage, ein Snap je Monat für dieses Jahr um einfach auf den entsprechenden vorherigen Datenstand zugreifen zu können.

Backup ist wichtig wenn Daten wichtig sind. Sind personenbezogene Daten dabei muss man eigentlich verschlüseln, auf dem Storage, beim Sichern und auf dem Backup. Geht z.B. bei ZFS mit einem Schlüssel je Dateisystem und auch im Zustand locked.

Könnte man alles haben, ist sogar OpenSource und kostenlos. Nennt sich Sicherheit nach Stand der Technik. Nur bei einem Mediaserver eventuell nicht so wichtig und selbst da steckt Arbeit drin um das wiederherzustellen.

Bei vergleichbaren Rahmenbedingungen hat sich nicht soviel getan.
Die Basic Auswahl hat den Fokus wohl auf dem Preis und weniger auf Datensicherheit und Performance. Auch ist die Erweiterbarkeit bei iTX trotz höherem Preis eher schlecht. Ein Fertig NAS für 500 Euro ist da aber auch nicht besser.

Prinzipiell bestimmt zunächst Datensicherheit, Performance und Preis die Auswahl. Zwei der Faktoren kann man wählen, der dritte ergibt sich. Daneben bestimmt Erweiterbarkeit und Extras den Preis.

Wenn man den Fokus eher auf Datensicherheit und Performance verschieben möchte und Erweiterbarkeit ein Thema ist (und man mindestens 100 Euro mehr ausgeben kann), dann dann könnte man allenfalls auf folgendes achten

uATX statt ITX Mainboard (billiger und erheblich erweiterbarer)
Ein Serverclass Mainboard. Bei Intel fangen Server-Chipsets mit C an (wegen ECC RAM)
Sockel 1151 oder neuerer 1151v2
Prozessor Celeron oder i3 (die können ECC und vt-d falls man mal virtualisieren möchte)
Intel Nic statt Realtek (die sind in jeder Hinsicht nur billig)

Bevorzugte Mainboardhersteller sind SuperMicro und Asrock, eventuell Gigabyte
Mainboards ab ca 150 Euro, CPU ab ca 40 Euro, ECC RAM je nachdem wieviel (ab 4GB)