SSD-Ausfall im Produktivserver: Wenn das ERP-System plötzlich nicht mehr reagiert

DATA REVERSE® analysiert und rekonstruiert ausgefallene Enterprise-SSDs im eigenen Labor in Leipzig. Was diese Datenträger von mechanischen Festplatten unterscheidet und warum ihre Rettung eigene Verfahren erfordert, zeigt ein Blick auf die Technik hinter der Ausfalllogik.

Was in einer SSD passiert, das von außen unsichtbar bleibt

Im Inneren einer SSD arbeiten NAND-Flash-Bausteine, ein Controller und je nach Modell ein zusätzlicher DRAM-Puffer. Der Controller verwaltet die Flash Translation Layer (FTL), die logische Blockadressen des Hostsystems den physischen Speicherbereichen im NAND zuordnet. Er steuert Wear Leveling, führt Fehlerkorrektur durch und verarbeitet TRIM- beziehungsweise Deallocate-Befehle.

Teile der Mapping-Informationen können während des Betriebs im flüchtigen Speicher vorgehalten werden. Kann die Firmware die persistent gespeicherten Metadaten nicht mehr lesen oder korrekt verarbeiten, initialisiert die SSD unter Umständen nicht mehr, obwohl noch Nutzdaten auf den NAND-Bausteinen vorhanden sein können.

Mit zunehmender Zahl der pro Zelle gespeicherten Bits – etwa bei TLC mit drei oder QLC mit vier Bit – liegen die auszuwertenden Spannungsbereiche enger beieinander. Dadurch steigen die Anforderungen an Fehlerkorrektur, Read-Retry-Verfahren und die korrekte Verarbeitung durch Controller und Firmware. Ohne die internen Mapping- und Verwaltungsinformationen lassen sich die ausgelesenen Rohdaten nicht unmittelbar wieder zu einer logischen Datenstruktur zusammensetzen.

SMART- beziehungsweise Health-Daten können Verschleißindikatoren anzeigen. Einen Firmware-Absturz kündigen sie in der Regel nicht an, weil es sich nicht um einen graduellen Verschleißprozess handelt, sondern um einen punktuellen Fehler im Controller oder in der Firmware.

Wann TRIM die Wiederherstellung erschwert

In Serverumgebungen können TRIM-, UNMAP- oder Deallocate-Befehle aktiv sein, sofern der gesamte Speicherpfad – Betriebssystem, Dateisystem, Controller, Treiber und SSD-Firmware – sie unterstützt und an die SSD weiterreicht. Für die Datenrettung sind sie insbesondere bei zuvor gelöschten Dateien oder freigegebenen Datenbankbereichen relevant: Wurden diese Blöcke als nicht mehr benötigt gemeldet, können ihre Inhalte durch die interne Speicherbereinigung bereits physisch entfernt worden sein. Aktive Daten, die seit dem letzten Backup neu geschrieben oder verändert wurden, sind davon nicht automatisch betroffen.

Ob TRIM aktiviert ist, sollte dokumentiert sein. Im Schadensfall beeinflusst diese Information die Einschätzung, welche Daten physisch noch auf dem Laufwerk vorhanden sein können.

Was ein SSD-Ausfall für den Geschäftsbetrieb bedeutet

Wenn eine Enterprise-SSD als alleiniger Datenbankdatenträger in einem Produktivserver ausfällt, steht je nach Systemarchitektur der gesamte Geschäftsbetrieb still. ERP, Produktionsplanung, Auftragsverwaltung, Rechnungsstellung – alles, was auf dieser Datenbank liegt, ist nicht mehr erreichbar.

Die Bezeichnung Enterprise-SSD beschreibt die vorgesehene Einsatzklasse und Belastbarkeit eines Laufwerks. Sie ersetzt jedoch weder redundante Datenträger noch eine überwachte und getestete Datensicherung. Eine einzelne SSD ohne unabhängige Wiederherstellungsmöglichkeit bleibt ein Single Point of Failure, unabhängig von ihrer Leistungsklasse.

Ein verbreitetes Risiko dabei: Sicherungsjobs, die nach einem Systemupdate nicht mehr korrekt starten und deren Fehlermeldungen im Ereignisprotokoll unbemerkt bleiben. Im Schadensfall stellt sich dann heraus, dass das letzte verwertbare Backup mehrere Wochen alt ist.

Wie DATA REVERSE® ausgefallene SSDs untersucht

Im Labor wird eine ausgefallene SSD zunächst darauf geprüft, ob sie sich über controller- und modellspezifische Diagnoseverfahren ansprechen lässt. Abhängig von der verbauten Controller-Familie können solche Zugänge ermöglichen, interne Metadaten auszulesen oder Teile der regulären Initialisierung zu umgehen. Auf diesem Weg lässt sich die Zuordnung zwischen logischen Blöcken und physischen NAND-Seiten rekonstruieren, sofern die Metadaten auf den NAND-Bausteinen noch intakt sind.

Führt dieser Weg nicht zum Ziel, bleibt als letztes Mittel das Auslöten der NAND-Flash-Chips und deren direkte Auslesung über spezialisierte Lesegeräte. Die ausgelesenen Rohdaten müssen anschließend abhängig von der Controller-Architektur fehlerkorrigiert, entscrambelt, zusammengeführt und anhand der internen Mapping-Strukturen rekonstruiert werden. Bei hardwareverschlüsselten SSDs hängt die Wiederherstellbarkeit zusätzlich davon ab, ob die benötigten Schlüssel und Metadaten noch zugänglich sind. Dieser Prozess setzt die Kenntnis der jeweiligen Controller-Architektur voraus und ist erheblich aufwendiger als bei Flash-Medien mit einfacherer Controllerlogik.

DATA REVERSE® ist nach ISO 9001 und ISO/IEC 27001 zertifiziert.

Was jetzt geprüft werden sollte

Backup-Jobs sollten täglich auf erfolgreichen Abschluss kontrolliert werden, idealerweise durch automatisierte Monitoring-Benachrichtigungen, die bei ausbleibender Bestätigung alarmieren.

SMART- beziehungsweise Health-Daten regelmäßig auswerten. Je nach Schnittstelle und Hersteller können Verschleißindikatoren, verfügbare Reserveblöcke, Medienfehler und die bereits genutzte Lebensdauer Hinweise auf den Zustand des Laufwerks geben. Sie ersetzen jedoch keine Redundanz und keinen getesteten Wiederherstellungsprozess.

Bei einem SSD-Ausfall den Server abschalten und weitere Einschaltversuche unterlassen. Die SSD sollte nicht initialisiert, formatiert, mit Firmware- oder Reparaturprogrammen bearbeitet oder wiederholt in anderen Systemen getestet werden. Modell, Seriennummer, Einbauposition und vorhandene Fehlermeldungen sollten für die Analyse dokumentiert werden.