Die 70.000-Stunden-Zeitbombe: Wie wir einen totgeglaubten Storage-Cluster ohne Datenverlust wiederbelebt haben

Wir haben eigens zwei Datenrettungslabore eingeschaltet, um wirklich jede Option zu prüfen — flashen wollte keines. Das Backup war ein halbes Jahr alt, ein ganzer Cluster stand — und am Ende kamen alle Daten verlustfrei zurück. Eine Fallstudie mit vollständiger technischer Dokumentation.

Der Anruf

„Unser RAID ist defekt. Angeblich sind zwei Caching-SSDs gestorben.” Der Patient: ein Fujitsu-PRIMERGY-Cluster, zwei Knoten, gemeinsamer SAS-Speicher, betrieben mit Windows Server Storage Spaces im Failover-Cluster.

Eines vorweg, weil es wichtig ist: Dies war kein Kunde aus unserem Managed Service, sondern eine externe Notfall-Anfrage. Der Zustand, den wir vorfanden — ungepatchte SSD-Firmware und ein nur halbjährliches Backup — entspricht ausdrücklich nicht dem, was wir unseren eigenen Kunden zumuten. Bei uns im Managed Backup wäre ein sechs Monate alter Datenstand schlicht undenkbar.

Unser Vorgehen ist immer gleich: erst rein passiv analysieren, nichts anfassen.

Die Diagnose

Ein klassisches Kaskaden-Szenario: Der Storage-Pool stand auf Degraded. Das 6-TB-Datenvolume (Parity-Space als Cluster-Shared-Volume) war offline und nicht mountbar. Fast alle VMs waren ausgefallen — inklusive dem einzigen Domaincontroller. Und weil dieser DC als VM auf genau diesem Storage lag, gab es keinen Kerberos-Logon-Server mehr — die Knoten konnten sich nicht mehr sauber authentifizieren.

Die Storage-Ebene entschlüsselten wir passiv mit PowerShell:

Get-PhysicalDisk | Select FriendlyName,MediaType,Usage,HealthStatus,OperationalStatus,Size
Get-StoragePool -FriendlyName <Pool> | fl HealthStatus,OperationalStatus,IsReadOnly
Get-VirtualDisk  | fl FriendlyName,ResiliencySettingName,WriteCacheSize,OperationalStatus,DetachedReason
Get-ClusterSharedVolume | Select Name,State,OwnerNode

Zwei SSDs meldeten sich mit 0 Byte und Lost Communication, Usage: Retired. In der Konfiguration waren sie das gespiegelte Journal / der Write-Back-Cache des Parity-Volumes. Beide gleichzeitig weg = keine Kopie des Journals = das Volume verweigert das Attachen. Die eigentlichen Nutzdaten lagen unberührt auf acht gesunden HDDs.

Die Ursache: ein Firmware-Countdown ab Werk

Die Verdächtigen: Toshiba PX02SMF020, 200-GB-SAS-SSDs. Diese Baureihe — und viele baugleiche OEM-Varianten von Dell, HPE und Fujitsu — hat einen berüchtigten Firmware-Bug: nach exakt 70.000 Betriebsstunden (~7 Jahre, 11 Monate) sperrt sich das Laufwerk beim nächsten Power-Cycle selbst. Es meldet dann 0 Byte und verweigert Lese- und Schreibbefehle. Die Hersteller haben dafür präventive Firmware veröffentlicht; ist die Sperre einmal ausgelöst, gilt sie weithin als Endstation.

Dass beide SSDs praktisch zeitgleich starben, war kein Zufall: identische Betriebsstunden, identische Spiegel-Last — derselbe Countdown lief synchron.

Entscheidend: Das ist kein Verschleißtod. Der NAND ist intakt — nur die Firmware hat sich gesperrt. Und das ist reversibel.

Wir haben zwei Datenrettungslabore eingeschaltet — beide winkten ab

Um wirklich keine Option auszulassen, haben wir parallel zwei spezialisierte Datenrettungsunternehmen eingeschaltet und den Fall geschildert. Beide lehnten es ab, die Laufwerke zu flashen — sie boten ausschließlich die klassische Datenrettung an: die SSDs im Labor auslesen.

Das hätte hier nichts gebracht. Auf den SSDs lagen keine Nutzdaten, sondern nur das gespiegelte Journal des Parity-Volumes. Ein Roh-Abbild dieser SSDs rekonstruiert kein Storage-Spaces-Volume — die echten Daten lagen ohnehin auf den HDDs. Der einzige verlustfreie Weg war, die physischen Laufwerke selbst wieder zum Leben zu erwecken, damit ihr Journal zurückkehrt. Genau das, was beide Labore ausschlossen.

Und der Druck war real: das jüngste Backup war ein halbes Jahr alt. Ein Restore hätte sechs Monate Datenstand gekostet. Reparatur statt Rettung war also nicht die elegantere, sondern die einzige akzeptable Option — und wir haben sie selbst umgesetzt.

Der technische Weg im Detail

1. Zustand am Laufwerk verifizieren

Mit dem quelloffenen openSeaChest ließen sich die Laufwerke trotz „0 Byte” ansprechen:

openSeaChest_Firmware --scan
# TOSHIBA  PDx  PX02SMF020  <SN>  5203

openSeaChest_Firmware -d PDx -i
# Drive Capacity: 0.00 / 0.00     MaxLBA: 0
# SMART Status: Unknown or Not Supported
# Firmware Download Support: Not Supported   <- Lock aktiv

openSeaChest_Firmware -d PDx --fwdlInfo
# Modes Supported: Full, Segmented           <- Download-Weg existiert doch

2. Die richtige Firmware besorgen

Generische Community-Images wurden von den OEM-gebrandeten Laufwerken mit Sense 5h/26h — Invalid Field in Parameter List abgewiesen — Signatur-Mismatch. Die Lösung war das seriennummer-gebundene Firmware-Paket des Herstellers — bei Fujitsu das „SSD Firmware update tool for PM2”, ein bootfähiges Flash-ISO.

Wichtig: Diese Firmware ist an die Server-Seriennummer gebunden und darf nicht öffentlich weiterverteilt werden. Beziehen Sie das Image immer über den Support-Kanal Ihres Herstellers für Ihre Laufwerke.

3. Firmware aus dem Boot-Image extrahieren

Nur das reine Firmware-Binary aus dem ISO — Schicht für Schicht via WSL, ohne Root:

# a) ISO auspacken -> INITRD.IMG, ohne mount, via pycdlib
python3 -c "import pycdlib;i=pycdlib.PyCdlib();i.open('FIXdisk.iso');\
i.get_file_from_iso('initrd.img',iso_path='/ISOLINUX/INITRD.IMG;1');i.close()"

# b) initrd (gzip + cpio) entpacken
zcat initrd.img | cpio -idm

# c) darin liegt das Root-FS als bzip2-Tarball
bunzip2 -k root.img.bz2 && tar -xf root.img

# d) Ergebnis: die signaturkorrekte Firmware
#    Data/PM252050100.frm  (FW 5205)  Header "PX02DHWF ... PM2:52:05:01:00"

Ein Blick in die Flash-Skripte des Herstellers verriet den Übertragungsmodus: WRITE BUFFER, Mode 7 (segmented).

4. Unter Windows flashen — der entscheidende Kniff

Erste Versuche brachen mitten im Segment-Stream ab (26h, dann 20h — Invalid Command Operation Code auf dem letzten Segment). Der Durchbruch: der Schalter, der genau diesen Final-Segment-Fehler ignoriert.

openSeaChest_Firmware -d PDx --downloadFW PM252050100.frm ^
    --downloadMode segmented --forceSCSI --forceFWDLPassthrough ^
    --fwdlIgnoreFinalSegment

# Firmware Download successful
# New firmware version is 5205
# Exit code 32 = Firmware Download Complete

5. Ergebnis kontrollieren

openSeaChest_Firmware -d PDx -i
# Firmware Revision: 5205
# Drive Capacity: 200.05 GB / 186.31 GiB
# SMART Status: Good

Von 0 Byte auf 200 GB, von Unknown auf Good — bei beiden Laufwerken. Mitsamt ihren Daten.

Das Finale: sauberer Wiederanlauf

Ein kontrollierter Neustart genügte, damit Windows die wiederbelebten SSDs neu einlas. Danach heilte sich der Cluster selbst: Der Pool ging auf Online / Fehlerfrei, das Quorum wurde gesund, erste VMs liefen wieder an. Weil das gespiegelte Journal zurück war, ließ sich das 6-TB-Parity-Volume verlustfrei wieder einbinden — kein „dirty” Force-Attach, kein Restore aus einem halben Jahr alten Backup.

Aus „das RAID ist tot” und der Aussicht auf sechs Monate Datenverlust wurde volle Datenrettung ohne einen einzigen verlorenen Datensatz.

Was Sie daraus mitnehmen sollten

1. Kennen Sie die Betriebsstunden Ihrer SSDs. Enterprise-SSDs der Baujahre ~2015–2017 nähern sich genau jetzt der 70.000-Stunden-Marke.
2. Spielen Sie Firmware-Fixes ein, bevor es knallt. Danach ist das Laufwerk immun — vorher ist es ein Zeitzünder.
3. Redundanz schützt nicht vor systematischen Fehlern. Zwei baugleiche Spiegel-SSDs gleichen Alters sterben gemeinsam.
4. Backups müssen aktuell und getestet sein. Ein halbjährliches Backup wie in diesem Fremdfall ist ein Alptraum — unsere Managed-Kunden sichern wir engmaschig, automatisiert und geprüft.
5. Virtualisieren Sie nie den einzigen DC auf dem Storage, dessen Verfügbarkeit von diesem DC abhängt. Dieser Deadlock verschärft jeden Ausfall.
6. Datenrettung ist nicht für jedes Problem das richtige Werkzeug. Wo zwei Labore nur „auslesen” wollten, war die Reparatur des Geräts der einzige verlustfreie Weg.

Sie sitzen vor einem „toten” Storage?

Bevor Sie ein teures Labor beauftragen oder Wochen an Backups verlieren: Reden Sie mit uns. Wir analysieren zuerst passiv, ohne etwas zu riskieren — und finden oft einen Weg, der günstiger, schneller und verlustfrei ist. Genau wie hier.

DATAZONE ist Ihr Partner für Storage, Virtualisierung und Datenrettung — jetzt Kontakt aufnehmen.