Gibt es eine Möglichkeit, die SSD vor Beschädigung durch Stromausfall zu schützen?

Wir haben eine Gruppe von Consumer-Terminals, auf denen Linux, ein lokaler Webserver und PostgreSQL installiert sind. Wir erhalten Erfahrungsberichte über Maschinen mit Problemen und nach einer Untersuchung scheint es, als ob ein Stromausfall aufgetreten ist und jetzt stimmt etwas mit der Festplatte nicht.

Ich war davon ausgegangen, dass das Problem nur darin besteht, dass die Datenbank beschädigt wird oder dass Dateien mit den letzten Änderungen verschlüsselt werden, aber es gibt auch andere seltsame Berichte.

• Dateien mit den falschen Berechtigungen
• Dateien, die zu Verzeichnissen geworden sind (z. B. index.phpist jetzt ein Verzeichnis)
• Verzeichnisse, die zu Dateien geworden sind
• Dateien mit verschlüsselten Daten

Es gibt Probleme mit der Datenbank, die beschädigt werden, aber das ist etwas, was ich erwarten könnte. Was mich mehr überrascht, sind die grundlegenderen Probleme mit dem Dateisystem - zum Beispiel Berechtigungen oder das Ändern einer Datei in ein Verzeichnis. Die Probleme treten auch in Dateien auf, die in letzter Zeit nicht geändert wurden (z. B. der Softwarecode und die Konfiguration).

Ist das "normal" für SSD-Korruption? Ursprünglich dachten wir, dass dies bei einigen billigen SSDs der Fall ist, aber wir haben dies bei einer bekannten Marke (Consumer Grade).

FWIW, wir machen kein autofsck beim unsauberen Booten (weiß nicht warum - ich bin neu). Wir haben USVs an einigen Orten installiert, aber manchmal funktioniert das nicht richtig usw. Dies sollte behoben werden, aber selbst dann können die Leute das Terminal unsauber herunterfahren usw. - es ist also nicht narrensicher. Das Dateisystem ist ext4.

Die Frage: Gibt es irgendetwas, was wir tun können, um das Problem auf Systemebene zu mindern?

Ich habe einige Artikel gefunden, die sich auf das Deaktivieren des Hardware-Caches oder das Aktivieren des Laufwerks im Synchronisierungsmodus beziehen, bin mir jedoch nicht sicher, ob dies in diesem Fall hilfreich sein könnte (Beschädigung von Metadaten und nicht zuletzt vorgenommene Änderungen). Ich habe auch eine Referenz zum Mounten des Dateisystems im schreibgeschützten Modus gelesen. Wir können das nicht tun, weil wir schreiben müssen, aber wir könnten eine schreibgeschützte Partition für den Code und die Konfiguration erstellen, wenn das helfen würde.

Dies ist ein Beispiel für ein Laufwerk sudo hdparm -i /dev/sda1:

Model=KINGSTON RBU-SMS151S364GG, FwRev=S9FM02.5, SerialNo=<deleted>
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7

Bei plötzlichem Stromausfall haben MLC / TLC / QLC-SSDs zwei Fehlermodi :

• Sie verlieren die In-Flight- und In-DRAM-Schreibvorgänge.
• Sie können alle Daten im Ruhezustand beschädigen, die auf der unteren Seite der zu programmierenden NAND-Zelle gespeichert sind.

Die erste Fehlerbedingung ist offensichtlich: Ohne Stromschutz gehen alle Daten verloren, die sich nicht auf einem stabilen Speicher befinden (dh: NAND selbst), sondern nur auf einem flüchtigen Cache (DRAM). Dasselbe gilt für klassische mechanische Festplatten (und dies kann das Dateisystem zerstören, das fsyncs nicht ordnungsgemäß ausgibt).

Die zweite Fehlerbedingung ist eine MLC + SSD-Angelegenheit: Wenn das High-Page-Bit zum Speichern neuer Daten neu programmiert wird, kann ein unerwarteter Stromausfall auch das untere Bit (dh die zuvor festgeschriebenen Daten) zerstören / ändern .

Die einzig wahre und naheliegendste Lösung besteht darin, einen DRAM-Cache mit Stromausfallschutz (in der Regel mit Batterie / Supercaps) zu integrieren, wie dies High-End-RAID-Controller seit jeher tun. Dies erhöht jedoch die Antriebskosten / -preise. Consumer-Laufwerke haben normalerweise keine durch Stromausfall geschützten Caches. Vielmehr verwenden sie eine Reihe von wirtschaftlicheren Lösungen als:

• teilweise geschützter Schreibcache (dh: Crucial M500 / M550 / M600 +);
• NAND-Änderungsjournal (dh Samsung-Laufwerke, siehe SMART PoR-Attribut);
• Spezielle SLC / Pseudo-SLC-NAND-Bereiche zum Absorbieren neuer Schreibvorgänge ohne vorherige gefährdete Daten (z. B. Sandisk, Samsung usw.).

Zurück zu Ihrer Frage: Ihre Kingstone-Laufwerke sind ultra-billig, verwenden einen nicht spezifizierten Controller und im Grunde genommen keine öffentlichen Spezifikationen. Es überrascht mich nicht, dass ein plötzlicher Stromausfall frühere Daten verfälscht hat. Leider kann Ihr Problem auch durch Deaktivieren des DRAM-Caches der Festplatte (mit dem von ihr befohlenen massiven Leistungsverlust) nicht behoben werden, da frühere Daten (dh Daten im Ruhezustand) durch unerwartete Stromausfälle beschädigt werden können und werden. Wenn sie auf dem alten Sandforce-Controller basieren, ist unter den "richtigen" Umständen sogar ein vollständiger Laufwerksblock zu erwarten.

Ich empfehle dringend, Ihre USV zu überprüfen und mittelfristig diese veralteten Laufwerke zu ersetzen.

Ein letzter Hinweis zu PostgreSQL und anderen Linux-Datenbanken: Sie werden den Cache der Festplatte nicht deaktivieren und sollten auch nicht dazu gezwungen werden. Sie geben stattdessen regelmäßig / erforderliche fsyncs / FUAs aus, um Schlüsseldaten für einen stabilen Speicher festzulegen. Dies ist die Art und Weise, wie Dinge getan werden sollten, es sei denn, es liegt ein sehr zwingender Grund vor (dh ein Antrieb, der sich mit ATA FLUSHES / FUAs befasst).

BEARBEITEN: Wenn möglich, sollten Sie eine Migration auf ein Prüfsummen-Dateisystem wie ZFS oder BTRFS in Betracht ziehen. Denken Sie zumindest an XFS, das über eine Journalprüfsumme und in letzter Zeit sogar über eine Metadatenprüfsumme verfügt. Wenn Sie gezwungen sind, EXT4 zu verwenden, sollten Sie erwägen, auto-fsck beim Start zu aktivieren (fsck.ext4 ist sehr gut bei der Reparatur von Beschädigungen).

Ja. Erhalten Sie keine supergünstigen SSDs - alles, was sich außerhalb des Low-End-Verbrauchermarkts befindet, verfügt über Kondensatoren und bietet umfassenden Schutz vor Stromausfall. Amd kostet wirklich nicht viel mehr.

Zunächst müssen die Ziele für die Wiederherstellungszeit und den Wiederherstellungspunkt definiert werden. Wie lange müssen Sie eines dieser Terminals wiederherstellen, und welcher Datenzeitpunkt ist akzeptabel? Vielleicht müssen Sie in ein paar Stunden in der Lage sein, das Backup der letzten Woche wiederherzustellen.

Alle möglichen seltsamen Dinge können mit Dateien passieren, wenn Schreibvorgänge im Flug verloren gehen. Die Priorität des Dateisystems ist die Wahrung der eigenen Metadatenkonsistenz. Möglicherweise bieten sie nicht die gleichen Garantien für Ihre Daten. Mit anderen Worten, fsckes kann nicht garantiert werden, dass Ihre Daten wiederhergestellt werden. Ihre Aufgabe ist es, Ihnen ein Dateisystem zur Verfügung zu stellen, das eingehängt werden kann.

Macht also. Installieren, konfigurieren und testen Sie, ob die USV das System ordnungsgemäß herunterfährt. Dadurch können Dateisystem-Caches und die Laufwerke selbst schreiben.

Und die Haltbarkeit der Schreibvorgänge auf den Datenträgern. Lesen Sie das Kapitel zur Zuverlässigkeit von PostgreSQL . Verwenden Sie das dort diskchecker.plverlinkte Skript, um einen Crash-Test durchzuführen und festzustellen, ob die SSDs lügen, wenn Schreibvorgänge in den nichtflüchtigen Speicher gelangen. Wenn es zu einem Verlust kommt, sollten Sie diese durch SSDs ersetzen, die bekanntermaßen einen Stromausfallschutz bieten.

Bearbeiten: Sie haben Details hinzugefügt, für die der Schreibcache aktiviert wurde. Sie können versuchen, Folgendes zu deaktivieren: hdparm -W0 /dev/sdaoder den entsprechenden Befehl für ein Hardware-Array. Referenz: RHEL-Speicheradministrationshandbuch .

Dateisystem-Schreibbarrieren erzwingen eine Reihenfolge von Journal-Commits. Es ist keine Garantie dafür, dass die Daten intakt sind, aber es ist sicherer für das Dateisystem mit einem flüchtigen Cache. Obwohl dies die Standardeinstellung ist, wird durch Hinzufügen der Mount-Option "Barriere" deutlich, dass Sie Wert auf Konsistenz gegenüber Leistung legen.

Endlich die letzte Verteidigungslinie. Führen Sie einen Wiederherstellungstest durch, um sicherzustellen, dass Sie Ihre Anwendung und Datenbank zum gewünschten Zeitpunkt wiederherstellen können. Dies ist nützlich für alle Arten von Datenverlust, nicht nur für Stromausfälle.