ubuntuusers.de

Moin, Leute!

Ich bin vor Kurzem von Windows mit nem dicken Storage Pool auf Ubuntu mit ZFS gewechselt. In beiden Fällen hatte ich keine Datenresilienz, da ich viel Platz benötigte und die Daten auch nicht allzu heilig sind bzw. wiederbeschafft werden können. Später wollte ich das zwar mal ändern, aber irgendwie kam es nie dazu.

Wenn unter Windows eine Platte ausfiel, waren die darauf befindlichen Daten verloren bzw. die Dateien futsch, die dort zum Teil abgelegt wurden. Das Entfernen der defekten HDD war aber nie ein Problem.

Mit ZFS irgendwie schon. Eine meiner Platten meldet etliche Lesefehler, beim Scrub wurden ein Dutzend dauerhafte defekte Dateien gemeldet. Die habe ich alle gelöscht (keine Ahnung, ob das irgendeinen Effekt hat). Gelistet werden die übrigens noch immer (z. B. mediapool:<0x10f00>, mediapool:<0x10e09> ...).

Versuche ich nun die defekte Platte mit remove zu entfernen, bricht der Vorgang nach wenigen GB ab, vermutlich wegen der Lesefehler.

Was ist denn aber die Alternative? Warten, bis die Platte komplett versagt und dann noch viel verlorengeht? Das kann doch nicht Sinn der Sache sein. ☺ Ich wurde sie gerne im noch funktionstüchtigen Zustand aus dem Pool nehmen und die Daten, die nicht gelesen werden können, sollen halt verworfen werden. Einzelne Platten zu verlieren, habe ich einkalkuliert, dass der gesamte Pool flöten geht, wäre aber schon eine mittelschwere Katastrophe.

PS: Ich bin eine absolute Linux-Laie und bin nur aufgrund der Stabilität zu Ubuntu gewechselt. Mein Server ist ein reines Datengrab.

Danke im Voraus! ☺

NAME        STATE     READ WRITE CKSUM
mediapool   ONLINE       0     0     0
  sdc       ONLINE      874    0     0
  sdf       ONLINE       0     0     0
  sde       ONLINE       0     0     0
  sda       ONLINE       0     0     0
  sdb       ONLINE       0     0     0
  sdd       ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        mediapool:<0x10f00>
        mediapool:<0x10e09>
        mediapool:<0x3013>
        mediapool:<0x10f28>
        mediapool:<0x10c43>
        mediapool:<0x10256>
        mediapool:<0x475b>
        mediapool:<0x10ea4>
        mediapool:<0x10ab6>
        mediapool:<0x10ecc>
        mediapool:<0x85f7>

pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
mediapool   25,9T  6,80T      3     13  16,5M  16,6M
  sdc       4,97T   497G      1      0  16,5M  3,38K
  sdf       4,80T   671G      0      1  1,71K  3,28M
  sde       3,67T  1,78T      0      2  2,29K  3,32M
  sda       4,35T  1,11T      0      2  1,53K  3,36M
  sdb       4,62T   851G      0      2  2,59K  3,29M
  sdd       3,51T  1,94T      0      3  3,33K  3,38M

Ich bin eine absolute Linux-Laie

Und dann nimmst du ZFS? 🙄 Mutig!

Hast du das schon probiert? (Replacing)

Generell: ZFS hat keinen Modus à la JBOD (was es dir ermöglichen würde einzelne Platten rauszunehmen). Es ähnelt eher einem RAID 0, wenn du einfach Platten zu einem Pool "zusammenfügst". Für ein JBOD ist ZFS definitiv die komplett falsche Wahl. Sorry für die drastische Unterstreichung, aber so ist es halt. ZFS sollte immer mit Redundanz angelegt werden (Mirror oder RaidZ). Bzw: die VDEVs selbst sind schon als Software- oder Hardware-Raid angelegt, dann geht auch ein Verbund, wie du ihn angelegt hast.

❗ Du solltest sofort ein komplettes Backup des Pools anlegen, um noch zu retten, was zu retten ist.

Dein Pool ist korrupt. Punkt. Du bist sehenden Auges ins Verderben gerannt, weil du das Risiko eines Plattendefekts in Kauf genommen hast. ZFS ist für solch ein Risiko-Spiel überhaupt nicht ausgelegt. Quasi jedes andere Dateisystem ist dafür besser geeeignet als ausgerechnet ZFS.

Eine bessere Lösung für ein JBOD ist mergerfs. Googel einfach mal danach.

Generell 2: Festplattenverbünde sollten immer eine Redundanz haben, damit man im Fehlerfall reagieren kann und es gar nicht erst zu Datenverlust kommt. Noch: ein Backup sollte man dennoch immer haben. (Ja, bei ca 20T ist das nicht ganz billig, ich weiß.)

— Tröste dich: du bist nicht der Erste, der ZFS falsch verwendet hat. 😉

Generell zu ZFS: es ist für den professionellen Einsatz gedacht. Eine sorgfältige Planung, wie man es einzusetzen gedenkt, wie man im Fehlerfall reagieren kann und wie man es ggf erweitert, ist unerlässlich. Die Kostenfrage sollte bei ZFS eher eine untergeordnete Rolle spielen. Mit ZFS spielt man nicht auf Risiko, so wie es leider bei dir der Fall ist. Mit ZFS kann man höchst komfortabel Backups erstellen. Und dies ist überhaupt der Hauptgrund, weshalb man ZFS als Dateisystem in Betracht ziehen sollte.

Tut mir leid, aber so sieht es aus. Wenn du die defekte Platte entfernst, dann geht der gesamte Pool offline. Deshalb: mache so schnell wie möglich ein Backup, solange der Pool noch online ist. Ich vermute, dass die defekte Platte "pending sectors" hat. Die werden immer mehr werden, und das immer schneller. Irgendwann wird es ZFS zuviel werden, und dann geht der Pool unrettbar offline. Dann hast du alle Daten verloren.

PS: 3 x 16T Platten bekommst du "schon" ab ca 3 x 250€. Als Raid Z1 hättest du 32T Kapazität im Pool. Vielleicht eine Erwägung wert. Eigentlich sollte man bei so großen Platten bereits auf Raid Z2 (mit 4 Platten) setzen, aber wenn die Kosten für dich relevant sind... — So ist es bei ZFS: lieber einmal protzen, als endlos frickeln. Mit zB 6 x 16T als RAID Z2 hättest du 64T Kapazität. Kostet halt ordentlich, aber man hat lange Ruhe, weil es superstabil läuft. Auch wenn mal Platten ausfallen.

Dickes Dankeschön für deine umfangreiche Antwort! Dass ich hier leider zu naiv rangegangen bin, ist mir nun klar. ;D

Ich habe eigentlich nur ZFS gewählt, weil das immer als Alternative zum Windows Storage Pool genannt wurde. Da hätte ich mal lieber weiter recherchiert.

Zum Pool: Ich habe alle soweit gesichert und den Pool plattgemacht bzw. als Raidz neu erstellt. Offenbar habe ich hier direkt den nächsten Fehler gemacht. Da die neue Platte noch im Versand war, hatte ich den Pool mit nur 5 Laufwerken erstellt, das sechste wollte ich dann bei Erhalt hinzufügen. Auch das geht übrigens beim Storage Pool mit Redundanz. 😛

Ich bin den Weg gegangen, weil ich im Netz gelesen hatte, dass sich auch zpools seit 2021 mit neuen Laufwerken erweitern lassen (https://freebsdfoundation.org/blog/raid-z-expansion-feature-for-zfs/). Aber offenbar habe ich auch da etwas falsch verstanden.

Was ich im Kontext der Speichererweiterung sonst finde, ist nur diese Variante: von den 5 Platten wieder 2 entfernen und im Pool zwei Mal je drei Platten als eigenes raidz einzubinden (attach). Das wäre dann zwar ein Pool, aber wenn ich das richtig verstehe, fehlen mir dann jedoch die Kapazität von zwei Festplatten. Oder?

Lässt sich das noch irgendwie elegant regeln oder muss ich den Pool wieder löschen und mit allen sechs Platten neu erstellen? Der Aufwand ist zwar noch überschaubar, da erst rund 5 TB vom Backup wieder aufgespielt sind, aber irgendwie trotzdem blöd. :p

Sorry für mein aktionistisches Handeln, durch das nun die nächste Frage entstanden ist. ☺)

Beste Grüße

starcook schrieb:

... oder muss ich den Pool wieder löschen und mit allen sechs Platten neu erstellen?

Exakt dieses.

Du bräuchtest aktuellste Quellen für die Raid-Z expansion. Die wirst du wohl nur bei FreeBSD finden. Bei openzfs findet sich jedenfalls noch gar nichts dazu. Das wird wohl auch noch geraume Zeit so bleiben...

Nochmal zur Zielsetzung von ZFS. Es geht um drei Punkte: Datensicherheit, Datensicherheit und Datensicherheit.

Das bedeutet, dass man kuckt, was man braucht, und dann baut man das. Dann lässt man es unverändert. Braucht man mehr Platz, so baut man einen neuen Pool mit mehr Platz und schiebt die Daten auf diesen. Und wenn das 2k€ für neue Platten bedeutet, dann ist das eben so.

Veränderungen macht man bei ZFS nur auf alleroberster Ebene: man kann zB mehrere Raid-Z- oder Mirror-Pools haben, die man zu einem Main-Pool (quasi ein Raid 0 aus Sub-Pools) zusammenfasst. Wird der Platz knapp, so fügt man einen weiteren Raid-Z- oder Mirror-Pool hinzu (und entfernt ggf einen alten, kleinen, wenn der schon zickt). Du siehst: wir reden hier von zig Platten. ZFS ist für wirklich große Datenmengen in einem produktiven Umfeld entwickelt worden.

Die o.g. Raid-Z expansion ist eher eine nette Spielerei. Das ist etwas für Bastler, die sich mit ZFS aus Spaß an der Freude vergnügen wollen.

Außerdem verlangt ZFS Wissen: zB ist es ein Unding einen Pool mit "sda, sdb, sdc..." aufzubauen. Du musst UUIDs o.ä. verwenden. Man muss vorher wissen, was man damit machen will. Die Verzeichnisstruktur sollte bereits beim Anlegen des Pools wohlüberlegt sein. ZB damit sich bei Erweiterungen keine Pfade ändern.

Puh, da hast du mich jetzt ordentlich desillusioniert. ☺

Ich merke, zfs passt absolut nicht zu mir. Ich brauche ein flexibles Tool wie den MS Storage Pool, bei dem ich jederzeit Laufwerke entfernen, austauschen und erweitern kann - auch mit Resilienz. Leider gibt es das bei scheinbar Ubuntu nicht - zumindest nicht als Komplettlösung.

Der Hinweis mit MergerFS ist top, das werde ich mir mal genauer anschauen. Das lässt sich evtl. mit unRAID kombinieren und würde dann ziemlich gut passen. Auch über SnapRAID bin ich jetzt öfter gestoßen. Ich werd mich mal einlesen. ☺

Ganz lieben Dank für deinen Rat bzw. deine Zeit - und vor allem: das Augenöffnen.

Ich brauche ein flexibles Tool ... mit Resilienz.

Bei Linux findet sich halt kein Entwickler für sowas. Die werden sich allesamt fragen "Warum in aller Welt sollte man ein Filesystem haben wollen, bei dem Datenverlust vorprogrammiert ist?" 😉