ZFS: Kaputte Dateien trotz Redundanz. Wieso?

R

Rosendoktor

Well-Known Member
Hallo zusammen,

ich hab' auf einem PC einen ZFS Pool aus 2x2TB HDDs, der als Datenspeicher für die beiden Dual Boot Installationen Debian und FreeBSD dient. Da liegen hauptsächlich Mediendateien und Backups der beiden Systeme drauf.

Da ich das seit 10 Jahren unveränderte und altertümliche Partitionsschema der Installationen modernisiere, hab' ich zunächst mit von USB gebooteten Wartungssystemen Backups der alten Systempartitionen und Homeverzeichnisse auf diesen Pool geschoben, per zfs send <dataset> > </pfad/zur/backup_datei>.zfs bzw. btrfs send <subvol> > </pfad/zur/backup_datei>.btrfs.

Beim zurückspielen der FreeBSD Backups trat dann aber ein Fehler auf, die Backup Dateien waren beschädigt. Ein Scrub über den betroffenen Pool ergab das:

Code: 
root@pollux:~# zpool status -v zshared
  pool: zshared
 state: ONLINE
status: One or more devices has experienced an error resulting in data
    corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
    entire pool from backup.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
  scan: scrub repaired 0B in 06:36:53 with 10 errors on Wed Feb 14 06:52:52 2024
config:

    NAME                                      STATE     READ WRITE CKSUM
    zshared                                   ONLINE       0     0     0
      mirror-0                                ONLINE       0     0     0
        212fe164-9bee-40c7-a9eb-f467e4225464  ONLINE       0     0    20
        67b004b4-edd5-4d27-9d8e-3b8b52c3a740  ONLINE       0     0    20

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

        zshared/backup:/Sirius/sirius_root.zfs
        zshared/backup:/Sirius/rsenger.zfs

Es ist also das Backup des Systems und meines Homeverzeichnisses kaputt. Datenverlust hab' ich zwar keinen (alle wichtigen Daten liegen auf einem Seafile Server und werden auf mehrere Rechner synchronisiert), aber es ist sehr ärgerlich da ich das komplette FreeBSD System neu aufsetzen und meinen Desktop neu einrichten muss.

Jetzt die Frage: Wie kann sowas passieren? Ich meine, jetzt verwende ich schon das vermeintlich modernste und beste Dateisystem, mit Checksummen und in Redundanz, und trotzdem gehen mir plötzlich wichtige, frisch geschriebene Dateien kaputt? Sowas ist mir in 30 Jahren FAT, NTFS, ext2/3/4 auf z. T. recht alten HDDs ohne Redundanz so nie passiert... :mad:

Die beiden HDDs sind zwar nicht die neuesten, die Smart Werte aber in Ordnung. Kann es am Controller oder an den Kabeln liegen? Wie können solche Checksummen Fehler auf beiden Platten gleichzeitig und wohl an derselben Stelle überhaupt passieren?

Ich bin gerade sehr enttäuscht von ZFS... :belehren:

Gruß, Robert
 
Zuletzt bearbeitet:
Für mich klingt das so, als hättest du den export auf das gleiche Dataset geschrieben, das du zu sichern versuchst?
 
Ich habe mal eine defekte Datenbank gehabt, weil mein RAM bzw. mein Mainboard rummurkste. Das hat ZFS auch nicht bemerkt.
 
zunächst: Redundanz bedeutet in dem Fall ja nur, dass du damit auch die Fehler redundant hast und nicht, dass auf magische Weise von einer Platte im Pool die korrekten Daten erkannt werden, während die andere schon Fehler hat. Also, Redundanz bedeutet nur eine größere Betriebssicherheit, weil du auch mit einer defekten Platte weiter machen kannst.

Wie kann so etwas passieren?
Ehrlich gesagt fallen mir so viele Möglichkeiten ein, dass mein kleines Hirn regelrecht ins Rotieren kommt.
Bei jeder Form der Datenübertragung wimmelt es doch von Fehlermöglichkeiten, selbst bei einfachen Schreibvorgängen innerhalb eines Systems. Deshalb beschränke ich mal auf die Möglichkeiten, die bei mir selbst in den letzten Wochen und Monaten häufig für Ungemach sorgten.
Am USB: defekte Kabel und Stecker, defekte Hubs (wobei defekt eben auch unzuverlässig meint, denn im normalen Gebrauch, beim Abspielen eines Media-Streams zB, merkt davon gar nichts, nur bei etlichen GB Daten am Stück passieren halt doch Fehler).
USB-Geräte selbst und USB-Reader. Ich benutze zB sehr sehr gerne Mini-Reader für Micro-SDHC, die ich wie einen USB-Stick gebrauchen kann. Super Sache und auf einem habe ich ein FreeBSD, doch wenn ich das benutze, ergeben sich zunehmend Fehler in Dateien (ZFS) und per zfs send brauche ich gar nicht erst zu versuchen, den Pool zu klonen. Es kommt immer zu Fehlern.
Das eben Gesagte gilt allerdings mit wenigen Einschränkungen auch für interne Medien, vor Allem für SSD. Defekte oder unzuverlässige Geräte, auch mit guten smartctl-Werten, defekte oder unzuverlässige Kabel, SATA-Daten, sowohl auch die Spannungsversorgung, überall mögliche Fehlerquellen.
Und dann, der RAM. Das war / ist leider schon wieder bei mir ein beinahe unkontrollierbares Übel auf einem PC (den ich aber trotzdem reaktivieren musste, weil der extra neu gekaufte vor kurzem seinen Geist aufgegeben hat). Schlechter RAM macht das beste COW-Dateisystem kaputt.

BTW: ob man wirklich ZFS als modern und bestes Dateisystem nennen kann, sei mal dahin gestellt. Es hat doch gefühlt inzwischen auch schon 20 Jahre auf dem Buckel und gerade in letzter Zeit mal wieder ein paar kleine Kratzer abbekommen. Im allgemeinen funktioniert es aber wirklich tadellos und die aufkommenden Fehler im laufenden Betrieb sind fast immer und ausschließlich die Folgen fehlerhafter HW.
 
Bei CKSUM exakt gleich viele Fehler deutet eher auf Hardware im Bereich Controller/Verkabelung. Das kann ein Spannungsabsacker der Festplatten vom Netzteil mit anschließendem Controllerreset (der kann auch durch Überhitzung vorkommen), quasi ein Folgefuckup sein. Geht das schnell genug, merkt man außer einer Bedenkpause beim Kopieren nichts.
Und dann hatten wir ja noch diese Perle: https://www.theregister.com/2023/11/27/openzfs_2_2_0_data_corruption/

Etwas weiter hergeholt, aber nicht unmöglich wäre ein Bug in der Plattenfirmware, der nach x-gelaufenen Stunden zu Tage tritt. Hat es alles schon gegeben, bis zum instant-Totalausfall. Das kann man eindämmen, indem man verschiedene Modelle gleicher Leistungsklassen benutzt oder eben im Desasterfall das Backup aus dem Hut zaubert.
Wenn schon die Flammen sichtbar sind, kann ZFS auch nichts mehr tun. :)

Fürs Gewissen und 4-Augen-Prinzip kannst du gerne noch die Ausgabe von smartctl -x -q noserial /dev/adaX beider Platten vor und nach einem long-Test posten. Den Test startest du mit smartctl -t long /dev/adaX und das geht alles parallel im Hintergrund, wird jedoch einige Stunden dauern.
 
vergessen und nun nicht in den vorherigen Post editiert:

Du musst doch nicht dein System neu installieren, weil dein Backup einige Fehler zeigt?
Einfach die Dateien löschen, oder das komplette Backup und dann ein neues Backup machen, sollte da zunächst genügen.

Allerdings korrigiert das keine defekte HW und wenn dann wieder Fehler auftauchen. sollte das nicht überraschen.
Neuinstallation korrigiert auch keine HW-Probleme.
 
mr44er schrieb:
Bei CKSUM exakt gleich viele Fehler deutet eher auf Hardware im Bereich Controller/Verkabelung. Das kann ein Spannungsabsacker der Festplatten vom Netzteil mit anschließendem Controllerreset (der kann auch durch Überhitzung vorkommen), quasi ein Folgefuckup sein. Geht das schnell genug, merkt man außer einer Bedenkpause beim Kopieren nichts.
Und dann hatten wir ja noch diese Perle: https://www.theregister.com/2023/11/27/openzfs_2_2_0_data_corruption/
Zum Vergrößern anklicken....

Wir sind hier doch bei FreeBSD, da ist das schon lange gefixed, nicht wie bei Ubuntu, wo es nach über zweieinhalb Monaten der Fix gerade mal in die phased Updates geschafft hat ;)

mr44er schrieb:
Etwas weiter hergeholt, aber nicht unmöglich wäre ein Bug in der Plattenfirmware, der nach x-gelaufenen Stunden zu Tage tritt. Hat es alles schon gegeben, bis zum instant-Totalausfall. Das kann man eindämmen, indem man verschiedene Modelle gleicher Leistungsklassen benutzt oder eben im Desasterfall das Backup aus dem Hut zaubert.
Wenn schon die Flammen sichtbar sind, kann ZFS auch nichts mehr tun. :)

Fürs Gewissen und 4-Augen-Prinzip kannst du gerne noch die Ausgabe von smartctl -x -q noserial /dev/adaX beider Platten vor und nach einem long-Test posten. Den Test startest du mit smartctl -t long /dev/adaX und das geht alles parallel im Hintergrund, wird jedoch einige Stunden dauern.
Zum Vergrößern anklicken....

Full ACK, würd auch auf jedenfall mal testen. Das mit den gleichen Checksums ist verdächtig. Smarttest und ev. nicht destruktiven writetest von badblocks wenn die Zeit dazu da ist. Ebenso einen memtest.
 
Man sollte schon ein paar Durchläufe machen, damit es aussagekräftig ist. Ich würds einfach nen (Arbeits)Tag laufen lassen bzw. über Nacht je nachdem wie es besser möglich ist.
 
pit234a schrieb:
zunächst: Redundanz bedeutet in dem Fall ja nur, dass du damit auch die Fehler redundant hast und nicht, dass auf magische Weise von einer Platte im Pool die korrekten Daten erkannt werden, während die andere schon Fehler hat. Also, Redundanz bedeutet nur eine größere Betriebssicherheit, weil du auch mit einer defekten Platte weiter machen kannst.
Zum Vergrößern anklicken....
Genau das aber sollte doch ZFS leisten. Also, mit Hilfe der Checksummen erkennen, dass ein Fehler auf einer der Platten vorliegt, und, wenn Redundanz vorhanden, diesen auch korrigieren können. Und ein zfs send erzeugt innerhalb des gesendeten Streams auch Checksummen, um Übertragungsfehler entdecken (nicht korrigieren) zu können.

Oder? :confused:
 
pit234a schrieb:
Du musst doch nicht dein System neu installieren, weil dein Backup einige Fehler zeigt?
Einfach die Dateien löschen, oder das komplette Backup und dann ein neues Backup machen, sollte da zunächst genügen.
Zum Vergrößern anklicken....
Das komplette Backup steckt in einer einzigen großen Datei. Die ist nun eben defekt. Die Wiederherstellung schlägt wegen der Fehler in der Datei fehl. Das alte System und das alte Home existieren nicht mehr, da die beiden Systemplatten neu angelegt/partitioniert wurden.

Komischerweise hat das Sichern und Wiederherstellen der Debian Installation (BTRFS auf /, ZFS auf /home) auf diese Weise problemlos funktioniert.
 
Naja ZFS hilft halt nur gegen Fehler auf der Platte, nicht beim Übertragen.

Bezüglich zfs send: Das prüft ja erstmal nur die Daten beim lesen, dann werden die übertragen und in deinem Fall in ein File geschrieben und die Blöcke dieses Files mit neuen Checksums versehen (zfs weiß ja nicht, dass es sich um einen zfs datastream handelt). Erst beim zfs recv werden die alten Checksums vom ursprünglichen zfs wieder gecheckt.
 
peterle schrieb:
Ich habe mal eine defekte Datenbank gehabt, weil mein RAM bzw. mein Mainboard rummurkste. Das hat ZFS auch nicht bemerkt.
Zum Vergrößern anklicken....
Glaube mal gehört zu haben dass defekter RAM ganz blöd ist zusammen mit ZFS. Da haue man sich viele Fehler rein. Ich habe zu meinem ZFS NAS (RAID) immer auch ein externes USB Laufwerk für alle Fälle.
 
Rosendoktor schrieb:
Also, mit Hilfe der Checksummen erkennen, dass ein Fehler auf einer der Platten vorliegt, und, wenn Redundanz vorhanden, diesen auch korrigieren können.
Zum Vergrößern anklicken....
Jep. Wenn nun aber beide Platten gleich 'lügen'/falsche Daten liefern, welcher glaubt man? In dem Fall kann man nicht korrigieren, nur erkennen, dass was fischig ist. Da wären drei Platten besser und ja, ich weiß...Stromkosten und so. Man sollte sich immer vorhalten, dass mehr Platten primär für die Korrektur besser sind und nicht Verschwendung von Speicherplatz. Wenn jetzt aber der Controller irgendwas macht/e und heimtückisch grinst, kann man auch mit vier Platten nicht korrigieren. Wie gesagt, die gleiche Zahl an Fehlern ist seltsam.
Es würde mich, falls es so ist, auch nicht wundern wenn du beide Platten an einem anderen Board nochmal scrubst, dass dann alles ok ist.
 
Lance schrieb:
Glaube mal gehört zu haben dass defekter RAM ganz blöd ist zusammen mit ZFS. Da haue man sich viele Fehler rein. Ich habe zu meinem ZFS NAS (RAID) immer auch ein externes USB Laufwerk für alle Fälle.
Zum Vergrößern anklicken....
zfs vergleicht salopp gesagt die Daten, welche geschrieben werden sollen, mit den Daten, welche wirklich geschrieben wurden; wenn die 1:1 stimmen, dann geht zfs davon aus dass der Schreibvorgang und die Daten passen;

die Daten kommen aus dem RAM - wenn das RAM defekt ist und einfach z.B. alle Bits auf dem Übertragungsweg zum zfs hin XOR-ed, dann schreibt zfs das 1:1 so auf die Platte und meldet zurück, dass alles passt - obwohl die Daten eben NICHT passen (außer, die Platte bzw deren Controller wäre zufällig auch so defekt, dass er die Daten nochmal XOR-ed :ugly:, dann wären alle glücklich und die defekte würden gar nicht auffallen)

@Rosendoktor - das was bei dir jetzt genau passiert ist (bzw warum), kann ich nicht sagen - es kann aber sein, dass entweder defekte Daten geschrieben wurden welche an zfs vorbei "defekt" geschrieben wurden wie oben im Beispiel beschrieben, oder halt Bits innerhalb der zfs Dateien hernach gekippt sind - alles schon vorgekommen, wobei es komisch wäre, wenn die auf nem mirror unreparierbar kippen;

ich selber hatte bisher nur einmal Datenverlust bei zfs - und das war wg einer defekten SAS Backplane, Symptome waren ähnlich deinen; für genau sowas hat man dann ein Backup (hoffentlich)
 
Also, ich hab' die gleiche Prozedur auch auf einer anderen, baugleichen Maschine mit noch älteren HDDs gemacht, da war ich übervorsichtig, es lief aber alles sauber.

Ich verstehe nach wie vor nicht was da passiert ist.

Während des Scrubs hab ich gelegentlich nachgeschaut, die Checksummenfehler haben synchron hochgezählt, die Datenfehler (oben nicht sichtbar wegen der -v Option) ebenfalls synchron dazu in Zweierschritten.

An den Platten oder der Verkabelung kann es mMn nicht liegen, da wäre nur eine Platte betroffen, und wenn doch beide, dann nicht so synchron, und ZFS hätte die Fehler beheben können.

Der Memtest ist ohne Fehler durchgelaufen. Kann es mMn aber auch nicht sein, denn wenn die Daten bereits vor dem Schreiben beschädigt worden wären, dann wäre zwar die interne Struktur der Datei kaputt (was beim zurückspielen dann wohl aufgefallen wäre), aber nicht die Dateien im Dateisystem selbst. Die lassen sich aber nicht mal mehr mit dem Dateimanager kopieren.

Eigentlich kann's nur noch der Controller sein, der Mist gebaut hat. Weiß jetzt aber nicht ob die HDDs am Mainboard oder am PCIe Controller hängen. Tauschen kann ich beides, Ersatzmainboard (älteres Modell... :)) liegt herum.

Danke nochmal,

Robert
 
@Rosendoktor verwendest du Verschlüsselung? Verfolge gerade mit leichtem Erschrecken einige Issues auf
github.com

Proposal: Consider adding warnings against using zfs native encryption along with send/recv in production · Issue #494 · openzfs/openzfs-docs

Among experienced zfs users and developers, it seems to be conventional wisdom that zfs native encryption is not suitable for production usage, particularly when combined with snapshotting and zfs ...
github.com github.com
"Input/output error", "Permanent zpool error", "Permanent errors"...
 
h^2 schrieb:
@Rosendoktor verwendest du Verschlüsselung?
Zum Vergrößern anklicken....
Ja, aber nur bei einem der beiden Datasets, deren Backup dann kaputt ging. Auch das Ziel verwendet Verschlüsselung, darum geht's aber in dieser Diskussion im Link gar nicht. Glaube nicht dass das mein Problem war, das vermute ich eher beim Zielpool.

Wie auch immer, die Maschine läuft wieder (hat doch ein paar Abende gedauert...), frisch und sauber, die kaputten Dateien hab ich gelöscht und beobachte mal den betroffenen Pool.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben