Dank ZFS betrug der Datenverlust nur etwa 10 Minuten

 (mastodon.social)
3 Punkte von GN⁺ 2023-08-24 | 1 Kommentare | Auf WhatsApp teilen
  • Eine 2 Jahre alte SSD fiel plötzlich aus, doch dank inkrementeller ZFS-Replikation konnte das System auf einem neuen Laufwerk wiederhergestellt werden; der tatsächliche Verlust beschränkte sich auf etwa 10 Minuten
  • Die gesamte Dateisystemstruktur wurde alle 10 Minuten per Snapshot erfasst und an ein NAS gesendet; zur Automatisierung kam zrepl zum Einsatz
  • Snapshots speichern den Zustand eines laufenden Systems zu einem bestimmten Zeitpunkt und übertragen nur Änderungen, sodass die Replikation auch im Heimnetzwerk im Hintergrund möglich war
  • Die Wiederherstellung war weit von automatischer Recovery entfernt: Ein 625-GiB-ZFS-Receive musste über Nacht laufen, außerdem musste der verschlüsselte Wrapper Key wiederhergestellt werden
  • ZFS bringt bei Einführung und Wartung einen hohen Aufwand mit sich, zeigt aber im realen Laufwerksausfall seine Disaster-Recovery-Wirkung, bis hin zur Wiederherstellung des Arbeitszustands

Nach dem SSD-Ausfall blieben nur 10 Minuten Verlust

  • Als der Nutzer den Laptop öffnete, um eine E-Mail zu senden, war der Bildschirm schwarz eingefroren; nach dem Neustart stellte sich heraus, dass die 2 Jahre alte SSD ausgefallen war
  • Nach der Wiederherstellung des Systems auf einem neuen Laufwerk war der Rechner wieder nutzbar, und der gesamte Datenverlust betrug nur etwa 10 Minuten
  • Der wiederhergestellte Laptop bootete genau an die Stelle zurück, an der die Arbeit unterbrochen worden war; auch die Browser-Tabs stellten die unvollendete Arbeit vom Vorabend wieder her
  • Die Idee, auf einem neuen Gerät den vorherigen Zustand fortzusetzen — wie in einer Chromebook-Werbung vor 12 Jahren — funktionierte in diesem Ausfallszenario tatsächlich

Eine Architektur, die eher Replikation als Backup ist

  • Statt lediglich ein Laufwerk zu sichern, wurde eine Replikation des gesamten Dateisystems verwendet
  • Im vergangenen Winter wurde für regelmäßige Backups von Computern für kreative Arbeit ein Heimnetzwerkspeicher aufgebaut; unter mehreren Optionen fiel die Wahl auf inkrementelle ZFS-Replikation
  • ZFS kann auch auf einem laufenden System effizient Snapshots zu bestimmten Zeitpunkten erstellen
  • Beim anschließenden Versand an eine andere Maschine werden nicht jedes Mal alle Daten erneut übertragen, sondern nur die geänderten Daten

Mit zrepl alle 10 Minuten ans NAS übertragen

  • Für die Automatisierung der Snapshot-Erstellung und Übertragung ans NAS wurde zrepl eingesetzt
  • Die Konfiguration sah vor, das gesamte Dateisystem alle 10 Minuten per Snapshot zu erfassen und zu übertragen
  • Dank inkrementeller Snapshots konnte die Replikation im Heimnetzwerk im Hintergrund laufen und die Kopie dennoch aktuell halten
  • Der letzte Lauf dauerte für die Übertragung 14 Sekunden und sendete etwa 64 MiB

Manueller Aufwand bei der Wiederherstellung

  • Die Systemwiederherstellung war ein Prozess, der Einarbeitung erforderte und in erheblichem Maße auf manuelle Arbeit angewiesen war
  • Der 625-GiB-ZFS-Receive musste über Nacht laufen
  • Die Snapshots waren vom ursprünglichen Computer verschlüsselt, sodass das NAS die Inhalte nicht lesen konnte
  • Um das Backup tatsächlich nutzen zu können, musste auch der verschlüsselte Wrapper Key wiederhergestellt werden
  • Bis zur ersten Bestätigung, dass die Daten entschlüsselt werden konnten, war der Wiederherstellungsprozess sehr nervenaufreibend

Einführungskosten und Hardwaretausch

  • Die Ersteinrichtung von ZFS erforderte den Austausch des gesamten Dateisystems und hatte daher hohe Einstiegskosten
  • Für den Betrieb ist viel einschlägiges Wissen nötig, und die Abläufe enthalten manuelle Arbeitsschritte
  • Dennoch war es ein Glücksfall, die Replikation eingerichtet zu haben, bevor die SSD zum ersten Mal ausfiel; in diesem Fall wurden die Vorteile von ZFS deutlich
  • Das ausgefallene Laufwerk war eine WD_BLACK SN850, die ursprünglich Teil der Framework-Bestellung war
    • Im Framework-Forum waren bereits beunruhigende Fälle zu sehen gewesen, in denen dieses Laufwerk plötzlich ausfiel oder nicht mehr bootfähig war
  • Noch am selben Tag wurden eine SK Hynix P41 SSD und ein Sabrent NVMe Enclosure von Amazon in etwa 3 Stunden geliefert

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-24
Meinungen auf Hacker News

  • Wer ZFS nutzt, ist damit besser vorbereitet als andere Nutzer von WD- oder SanDisk-SSDs
    https://petapixel.com/2023/08/08/sandisk-portable-ssds-are-failing-so-frequently-we-can-no-longer-recommend-them/
    https://www.theverge.com/22291828/sandisk-extreme-pro-portable-my-passport-failure-continued
    https://news.ycombinator.com/item?id=37042587
    https://www.theverge.com/23837513/western-digital-sandisk-ssd-corrupted-deleted-questions
    https://news.ycombinator.com/item?id=37188736

  • Kurz bevor ich der Linux-Welt endgültig den Rücken gekehrt habe, habe ich angefangen, mich ein wenig in den Eisberg namens btrfs einzugraben, und fand das ziemlich interessant.
    Bei vielen Funktionen wie Backup-Innovationen und Disk-Konfiguration schien viel Potenzial zu stecken. btrfs ist nicht ZFS, aber funktional gibt es Überschneidungen, und es kommt auch so etwas wie einem „ZFS für Arme“ nahe. Außerdem ist ZFS bei Lizenzierung, Packaging und Aufnahme in den Kernel etwas heikel, sodass btrfs auf bestimmten Betriebssystemen deutlich sinnvoller läuft.
    Als ich in einer Linux User Group erzählte, dass ich zum Neustarten eines Computers den Netzstecker ziehen musste, wurde ich für diese dumme Aktion ordentlich zusammengestaucht und bekam den Rat, ZFS zu verwenden. Wenn man allerdings bedenkt, dass dieses System ein Raspberry Pi war, kann man darüber, welche der beiden Handlungen klug ist, auch anders denken.

    • Beim Pi kann es zwar zu Dateisystembeschädigungen kommen, aber da ich bei jeder Image-Installation ein Skript laufen lasse, das überall tmpfs einhängt und die meisten nutzlosen Logs abschaltet, habe ich das selbst nie gesehen.
      Solange man die SD-Karte nicht quält, laufen solche Geräte sehr stabil weiter. ZFS sieht wirklich großartig aus, aber selbst wenn ich mir irgendwann ein NAS kaufe, werde ich wohl kein Geld für Hardware ausgeben wollen, die ZFS ausführen kann, und stattdessen einfach RAID und ext4 verwenden.
      btrfs habe ich weiter gemieden, weil ich alle paar Monate Beiträge wie „BTRFS hat meine Daten vernichtet“ sah und anschließend Debatten darüber, ob das wirklich die Schuld von btrfs war. In letzter Zeit sehe ich solche Beiträge anscheinend seltener, vielleicht ist es also Zeit, es mir wieder anzusehen.
    • Aus Neugier: Was war der Auslöser dafür, dass du die Linux-Welt ganz verlassen hast? Was könnte die „Community“ aus dieser Erfahrung lernen, um für andere besser zu werden?
    • Das Einzige, was mir an btrfs wirklich nicht gefällt, ist, dass es leicht zu Fragmentierung kommt.
      Besonders bei sparse VM-Images ist das so, und für diesen Zweck halte ich zvols für deutlich besser.

  • Vor ein paar Jahren gab es die Kondensatorplage, und jetzt frage ich mich, ob wir eine Speichergeräteplage erleben.
    Es wird absurd, wie alle Speichergeräte immer schlechter werden. WD ruiniert HDDs mit SMR, und Hersteller sagen, dass drei Jahre Betriebszeit für SSDs und HDDs schon zu lang seien — das ist kein Witz. Allein dieses Jahr ist mir eine Kingston-SSD gestorben; gut, die war etwa acht Jahre alt. Aber eine portable WD-HDD ist nach ungefähr zwei Jahren gestorben.
    Das Internet ist heutzutage voll von Datenverlusten und Lebensdauerproblemen. Vor 20 Jahren waren HDDs auch keine Dinge für die Ewigkeit, aber ich erinnere mich, dass sie zumindest definitiv länger hielten als die nutzbare Lebensdauer des Computers, mit dem man sie gekauft hatte.

    • Heutige Festplatten haben deutlich mehr Glück als vor 20 Jahren.
      Vor 20 Jahren war die Ära der berüchtigten IBM Deathstar-Laufwerke, bei denen sich die Magnetschicht buchstäblich von den Plattern löste. Es gab auch schreckliche Maxtor-Laufwerke, die nach ein bis zwei Jahren starben, und nachdem Seagate Maxtor übernommen hatte, wurden auch Seagate-Laufwerke eine Zeit lang unzuverlässig. Ich betrieb einen Server mit etwa acht Disks und musste ständig ungefähr eine pro Jahr austauschen.
      Im Gegensatz dazu helfe ich heute bei der Verwaltung eines ZFS-Servers mit über 20 Laufwerken, und die Lebensdauer der Laufwerke liegt grob bei vier bis fünf Jahren. Außerdem wurden Computer damals viel schneller veraltet. Heute ist ein sechs Jahre alter Computer noch völlig brauchbar, aber damals spürte man es schon deutlich, wenn ein Computer drei Jahre alt war.
    • Keine Sorge. Bald werden auch Chips nach ein paar Jahren anfangen, Fehlfunktionen zu zeigen.
      Wir stoßen an Skalierungsgrenzen, und das exponentielle Wachstum verlangsamt sich.
    • Persönlich erinnere ich mich daran, dass früher bei mir und Leuten in meinem Umfeld HDDs gelegentlich ausfielen.
      Heute passiert mir das bei SSDs fast nie. Sogar eine alte Intel-SSD aus den späten 2000ern, die als problematisch bekannt war, funktioniert noch immer tadellos in demselben alten MacBook, das ich nach ein paar Jahren Nutzung meiner Mutter gegeben habe. Ich frage mich, wie die tatsächlichen Daten dazu aussehen.
    • Alle WD-Laufwerke, die ich in den letzten zehn Jahren gekauft habe, haben wie erwartet funktioniert. Das schließt auch NAS-Modelle ein, die ich nach der Einführung von SMR gekauft habe, weil ich eben darauf geachtet habe, dass es Plus oder Pro sind und nicht einfach Red.
      Auch mit SSDs hatte ich Glück, aber auf dem Desktop lege ich das Verzeichnis /home und RAID-Arrays weiterhin lieber auf alte rotierende Laufwerke, daher verwende ich nur kleine SSDs.
      Es gab zwei Ausnahmen. Ich hatte zwei WD Red von vor der SMR-Zeit aus einem alten NAS genommen, um sie durch größere Platten zu ersetzen; sie waren vollständig in Ordnung und wurden in antistatischen Beuteln in einer Schublade gelagert. Etwa 2,5 Jahre später brauchte ich Ersatzplatten, holte sie heraus und prüfte sie — beide funktionierten nicht mehr. Eine war komplett tot, die andere wurde gerade noch erkannt, war aber nicht lesbar. Die erste tauchte beim Anschließen überhaupt nicht auf; ich reinigte alle Kontakte, einschließlich der Pins auf der Controller-PCB, aber es half nichts, also warf ich sie schließlich weg. Die zweite war erst nach einer vollständigen Neuformatierung wieder nutzbar, aber selbst mit testdisk gab es keine Möglichkeit, die alten Daten wiederherzustellen. So etwas hatte ich weder erlebt noch erwartet, und ehrlich gesagt macht mir das ziemlich Sorgen.
    • Vor etwa 20 Jahren gab es auch die HGST „Deathstar“, ein Laufwerk, das so schlecht war, dass es sogar zu einer Sammelklage kam.
      Disks sind schon immer zufällig gestorben, und das war einer der Gründe, warum Sun ZFS entwickelt hat.

  • Ganz kurz zusammengefasst: Der Mastodon-Thread verweist auf https://zrepl.github.io.
    „zrepl ist eine integrierte One-Stop-Lösung für ZFS-Replikation.“

    • Weiß jemand, wie sich zrepl und sanoid/syncoid unterscheiden, abgesehen davon, dass zrepl in Go geschrieben ist und sanoid/syncoid Perl-Skripte sind?
    • Es sieht so aus, als müsste man mit einem Daemon kommunizieren, der auf dem Speicherserver läuft.
      Wenn man zum Beispiel S3 direkt als Storage nutzen könnte, wäre das großartig.

  • Zrepl ist ein wichtiger Grund, warum ich mein Leben als digitaler Nomade beruhigt führen kann.
    Ein Skript, das ungefähr einmal pro Nacht läuft, öffnet einen LUKS-geschützten ZFS-Pool mit separatem Header und kopiert alle Snapshots. Dieses NVME-Gehäuse befindet sich immer in der „Tasche“, die ich ständig bei mir habe.
    Dank dieser Konfiguration und NixOS kann ich einen identischen neuen Laptop in etwa zehn Minuten provisionieren. Vor Kurzem habe ich auch Offsite-Replikation hinzugefügt, sodass die Wahrscheinlichkeit eines gravierenden Datenverlusts selbst bei einem komplett schlimmen Raubüberfall nahezu null ist.
    Zrepl ist wirklich hervorragende Software. Es ist leicht, damit anzufangen, aber zugleich so ausgefeilt und leistungsfähig, dass man bei Bedarf an allen Stellschrauben drehen kann. Ich kann es gar nicht genug loben.

    • Das klingt deutlich sicherer als bei den meisten Leuten, bei denen ein einzelner Diebstahl, Brand, eine Überschwemmung oder eine andere Katastrophe alles beenden würde.
    • Hast du sanoid/syncoid schon ausprobiert? Was bietet Zrepl im Vergleich dazu zusätzlich?
    • Es wäre schön, wenn du aufschreiben könntest, wie diese Konfiguration funktioniert. Klingt ziemlich interessant.

  • Könnte es den Tod der SSD beeinflusst haben, dass das Dateisystem alle 10 Minuten per Snapshot gesichert wurde?

    • ZFS ist speziell und nutzt Copy-on-Write, daher sind die Kosten für das Erstellen von Snapshots gering.
      Intuitiv würde ich vermuten, dass selbst sehr häufige Snapshots nur relativ wenig zusätzliche Schreiblast erzeugen. Trotzdem wären wissenschaftliche Messungen dazu schön.
      Auf einigen Servern, die ich früher betreut habe, habe ich mit ZFS minütliche, stündliche und tägliche Snapshots erstellt. Die minütlichen Snapshots wurden nach 60 Minuten gelöscht, und ein Cron-Job auf einer anderen Maschine sicherte die stündlichen und täglichen Snapshots. Stündliche Snapshots wurden ungefähr 72 Stunden aufbewahrt, tägliche dauerhaft. Die minütlichen Snapshots waren dazu gedacht, manuelle Fehler bei SQL-Migrationen rückgängig machen zu können, und das funktionierte gut.
      Auch heute nutze ich ZFS auf einem FreeBSD-Server, aber meine aktuellen Projekte haben wenig Traffic und nur selten wichtige Datenänderungen. Deshalb erstelle ich auf meinem privaten Server etwa einmal pro Woche manuell Snapshots und stoße das Backup von einem anderen Server aus manuell an. Außerdem mache ich inzwischen nur noch Snapshots des Dateisystembereichs mit PostgreSQL-Datenbanken und Anwendungsdaten. Um Betriebssystemdaten kümmere ich mich nicht mehr besonders. Bei einem schweren Hardwaredefekt würde ich das OS neu installieren; wichtige Konfigurationswerte notiere ich, und wenn das Backup-Skript läuft, kopiert es diese Werte statt allerlei sonstigem Kleinkram.
    • Das ist eher unwahrscheinlich.
      Snapshots schreiben nicht viel, und sowohl SSDs als auch ZFS arbeiten mit Copy-on-Write. Das heißt, die Schreibkosten nach einem Snapshot sind dieselben wie davor.
      Allerdings fehlt hier Kontext. Weder SSDs noch ZFS mögen es, voll oder fast voll zu sein. Wenn die Arbeitsdaten etwa 650 GB groß waren und das Laufwerk 1 TB hatte, könnte die Laufwerksbelegung durch Snapshots leicht über 90 % gestiegen sein. Schon das allein könnte ZFS Probleme bereitet haben.
    • Soweit ich es verstehe, bedeutet ein Snapshot in ZFS, ein Metadatenobjekt und einige Datenreferenzen zu schreiben.
      Bei 100 GB Daten, 128K Blockgröße und 64-Bit-Pointern würde ich schätzen, dass während eines Snapshots ungefähr 5 MB neu geschrieben werden. Wenn man das 6-mal pro Stunde bzw. 52.560-mal pro Jahr macht, ergibt das rund 256 GB pro Jahr. Das dürfte wahrscheinlich weniger als 1 % der Schreibhaltbarkeit einer SSD sein. Daher wäre ich überrascht, wenn 10-Minuten-Snapshots ein wesentlicher Grund wären.
      Ich kann mich irren, und die Schätzung entstand mit Hilfe einer nicht besonders verlässlichen Quelle. Korrekturen sind willkommen. Aber wenn meine Schätzung eher zu hoch liegt und es trotzdem unwahrscheinlich ist, dass sie die Lebensdauer beeinflusst, ist der Punkt möglicherweise ohnehin nicht sehr relevant.
    • Eher unwahrscheinlich. Ein Snapshot markiert ungefähr die zuletzt geschriebenen Blöcke und verhindert, dass frühere Blöcke verändert werden.
      ZFS ist Copy-on-Write, daher entstehen bei Dateiänderungen dieselben Schreibvorgänge; nur werden einige alte Daten nicht gelöscht.
    • Laut einem Kommentar[1] auf irgendeiner zufälligen orangefarbenen Website könnte die minimale Schreibgröße moderner Flash-Chips bei etwa 100 MB liegen.
      Dann würden 5 MB Schreiblast alle 10 Minuten tatsächlich 600 MB pro Stunde, 4,8 TB pro 8-Stunden-Arbeitstag und 24 TB pro 40-Stunden-Woche bedeuten; bei einem 1-TB-Laufwerk wären das in Echtzeit 3,43 DWPD und über 2 Jahre Echtzeit 2500 TBW[2].
      Die offizielle Schreibhaltbarkeit der SN850 liegt bei 600 TBW, wobei dieser Wert wegen Garantiethemen natürlich wahrscheinlich konservativ niedrig angesetzt ist. Zufällig sind 2500 TB auch ein üblicher Haltbarkeitswert vieler SSDs in diesem Markt. Insgesamt klingt es also nicht völlig unmöglich.
      Falls sie noch lebt, wäre interessant, was der Controller in den SMART-Daten meldet. Unter Linux sollte apt install smartmontools; smartctl -s on /dev/sda; smartctl -A /dev/sda eine Tabelle ausgeben[4]. Unter Windows kann man CrystalDiskInfo[3] installieren.
      1: https://news.ycombinator.com/item?id=29165202
      2: DWPD: Drive Writes Per Day, TBW: Total Bytes Written – in Terabyte
      3: https://crystalmark.info/en/software/crystaldiskinfo/
      4: „Pre-fail“ bedeutet, dass sich der Wert kurz vor einem Ausfall ändern sollte, und „Old_age“ bedeutet, dass es ein altersbezogener Wert ist – nicht „das ist schlecht und fällt bald aus“ oder „dieses Laufwerk ist alt“. Bei allen Einträgen wird immer Pre-fail oder Old_age angezeigt. Ich finde, jemand hätte das schon vor langer Zeit in „somewhat_boolean“ und „life_remain“ umbenennen sollen.

  • Ich mache normalerweise inkrementelle Apple-Time-Machine-Backups auf einen Synology-Server mit rotierenden Festplatten.
    Wenn ich riskante Arbeiten mache oder die Maschine upgrade, spiegele ich das interne Laufwerk manchmal auch auf eine externe SSD. Diese Methode funktioniert gut. Eine Wiederherstellung mit Time Machine kann ziemlich langsam sein, aber die meisten wichtigen Daten liegen in Git und gehosteten Repositories, daher war das kein großes Problem. Gelegentlich nutze ich Time Machine, wenn ich eine einzelne Datei zurückholen möchte.
    Ich habe auch eines der berüchtigten[0] SanDisk-Laufwerke, verwende es aber nicht für wichtige Zwecke. Darauf liegen nur Spielebibliotheken oder Ähnliches. Als Mac-Nutzer sind Spiele kein großer Faktor, und wenn sie sterben, werde ich nicht weinen.
    [0] https://arstechnica.com/gadgets/2023/08/sandisk-extreme-ssds-are-worthless-multiple-lawsuits-against-wd-say/

    • Ich nutze ebenfalls Time Machine. Ich habe die App https://tclementdev.com/timemachineeditor/ installiert, damit sie TM-Backups manuell auslöst, wann immer die Maschine im Leerlauf ist.
      Das scheint deutlich besser zu funktionieren als Apples automatische oder zeitbasierte Backups.
    • Ich habe Time Machine aufgegeben. Mit Synology und atalk usw. hat es bei mir kaum jemals länger als ein oder zwei Monate zuverlässig funktioniert.

  • Meine Snapshots sind auf dem Quellcomputer verschlüsselt. Dass das NAS sie nicht lesen kann, ist ziemlich cool.
    Um das Backup zu nutzen, musste ich daher auch den verschlüsselten Wrapper Key wiederherstellen. Ohne zu lügen: Bis ich die erste Bestätigung hatte, dass ich die Daten entschlüsseln kann, war das ziemlich beängstigend.
    Bei einer maßgeschneiderten Backup-Lösung sollte man nicht davon ausgehen, dass sie funktioniert, bevor man nicht tatsächlich regelmäßig geprüft hat, ob sich die Daten wiederherstellen lassen.

    • Das gilt genauso für nicht maßgeschneiderte Backups.
    • Ich hatte immer nur daran gedacht, für den Fall der Fälle eine Kopie des LUKS-Headers auf einer separaten Festplatte aufzubewahren.

  • Die nahe Zukunft unter Linux ist hier bcachefs.
    https://bcachefs.org/

    • Was kann bcachefs besser als BTRFS oder ZFS?
    • Für „nahe Zukunft“ ist es schon seit sieben Jahren in Entwicklung und wurde noch nicht upstream aufgenommen.
      Die Arbeit am Upstreaming läuft allerdings.
    • Gibt es eine kurze Zusammenfassung, warum man darauf gespannt sein sollte? Hat es irgendwelche coolen Features?

  • „Bis ich die erste Bestätigung hatte, dass ich die Daten entschlüsseln kann, war das ziemlich beängstigend“ klingt so, als sei der Prozess weniger getestet und weniger dokumentiert gewesen als optimal.
    Bei Heimsystemen oder privaten Desktops ist das nicht besonders selten. Bei Produktionsservern möchte man das Wiederherstellungsverfahren aber trotzdem nicht erst vor Ort improvisiert herausfinden müssen.

    • Stimmt. Ich wusste, dass ich alle für die Wiederherstellung nötigen Bestandteile hatte, und hatte es sechs Monate zuvor einmal getestet, aber anfangs habe ich den falschen Schlüssel kopiert.
      Als das Laden fehlschlug, war es kurz düster, aber mir wurde der Fehler schnell klar. In solchen Momenten des Scheiterns kommt eine Art Klarheit auf, in der die Lücken aller Prozesse grell offensichtlich werden.