Blog von RecoverySoftware

BitLocker To Go verwendet dieselbe Verschlüsselungstechnologie wie BitLocker für Systemlaufwerke und kommt auf Wechseldatenträgern zum Einsatz – etwa auf externen HDDs, SSDs und USB-Sticks. Die Vorgehensweise zum Entsperren entspricht grundsätzlich der in unserem Leitfaden zur Datenrettung von einem mit BitLocker verschlüsselten internen Laufwerk. In der Praxis weisen externe Laufwerke jedoch andere Fehlerbilder auf: Es steht kein TPM als alternative Schutzkomponente zur Verfügung, eine sichtbare FAT32-Partition wird häufig fälschlicherweise für das gesamte Laufwerk gehalten, und während des Vorgangs kommt es häufiger zu einer physischen Trennung vom Computer. Dieser Leitfaden behandelt die Besonderheiten der Datenrettung von externen Festplatten und USB-Laufwerken.

In diesem Artikel wird erläutert, wie das TPM-Modul auf dem Computer aktiviert wird.

Die Wiederherstellung von Daten von einem mit BitLocker verschlüsselten Laufwerk ist nicht in jedem Fall dasselbe Problem. Ein vergessenes Kennwort, während der Wiederherstellungsschlüssel noch vorhanden ist, lässt sich in fünf Minuten beheben. Eine beschädigte Partitionszuordnungstabelle auf einem verschlüsselten Volume oder ein Systemlaufwerk, das nach einer Hardwareänderung die Bindung an das TPM verloren hat, ist eine völlig andere Situation: Das Volume ist weiterhin vorhanden, aber es zu finden und zu entsperren erfordert mehr als die Eingabe eines Kennworts in Windows. Dieser Leitfaden behandelt beide Fälle – für das Systemvolume (C:) und jedes weitere verschlüsselte Datenvolume (D:).

Zwei Festplatten sind in Ihrem Synology SHR-1-Array ausgefallen. DSM meldet den Speicherpool als abgestürzt und gibt an, dass die Daten nicht wiederhergestellt werden können. Die Datenrettung bei SHR-1 nach einem doppelten Festplattenausfall ist Gegenstand dieses Artikels – und die Situation ist differenzierter, als die DSM-Meldung vermuten lässt. Ob Ihre Daten wiederherstellbar sind, hängt nicht allein von der Anzahl der ausgefallenen Laufwerke ab, sondern davon, wie sie ausgefallen sind und in welchem Zustand sich die verbleibenden Laufwerke befinden.

Sie haben in Ihrem Synology‑SHR‑Array eine 4‑TB‑Festplatte durch eine 8‑TB‑Festplatte ersetzt. Der Wiederaufbau (Rebuild) begann, lief eine Zeitlang — und brach dann ab. DSM zeigt Degraded, Crashed oder der Fortschrittsbalken hat sich seit Stunden nicht mehr bewegt. Das NAS kann dabei vollständig nicht mehr reagieren. Dieser Artikel behandelt die Datenrettung nach einem Absturz des SHR‑Wiederaufbaus: was im Array tatsächlich passiert ist, wie Sie den aktuellen Zustand auslesen, ohne die Lage zu verschlimmern, und wie Sie Ihre Dateien wiederherstellen.

Das NAS ist ausgefallen. Die Festplatten sind intakt. Schließen Sie diese an einen Windows- oder Linux-Rechner an, erscheint entweder die Meldung „Sie müssen das Laufwerk formatieren“ oder die Laufwerke sind gar nicht sichtbar. Es handelt sich nicht um Datenverlust, sondern um ein Zugriffsproblem. Im Gegensatz zu Fällen, in denen die Festplatten selbst ausfallen, bleiben die SHR-Volumendaten bei einem defekten Synology-Mainboard physisch unberührt. Was Sie wiederherstellen müssen, ist nicht die Rohdaten selbst, sondern der Zugriff auf die mehrschichtige Struktur, die Synology zur Speicherung verwendet.

In einem Array mit einfacher Parität sind zwei Festplatten ausgefallen, in einem mit doppelter Parität drei. Unraid kann das Array nicht starten, und selbst wenn es das könnte, wären die Daten auf den ausgefallenen Laufwerken allein durch die Paritätsinformationen mathematisch nicht wiederherstellbar. Dies ist der Punkt, an dem die Speicherredundanz endet und die eigentliche Datenrettung beginnt.

Die Festplatte ist physisch vorhanden, SMART meldet keine Fehler und das Unraid‑Array wurde ohne Probleme gestartet — dennoch fehlt ein Share und die Web‑GUI zeigt das Laufwerk als „Unmountable“ (nicht einbindbar) an. Dies ist ein Fall von Dateisystemkorruption und gehört zu einer anderen Fehlerklasse als ein Hardware‑Ausfall.

Ein Einzelplattenausfall in einem Unraid-Array ist ein vorhersehbares, handhabbares Ereignis — vorausgesetzt, man reagiert korrekt. Das System bleibt funktionsfähig, Daten bleiben zugänglich und es gibt einen definierten Weg zur vollständigen Wiederherstellung. Das ist keine Zufälligkeit, sondern ergibt sich direkt aus der Struktur, mit der Unraid seine Arrays organisiert.

Dieser Artikel erläutert die Mechanik hinter diesem Schutz, das korrekte Vorgehen beim Austausch einer ausgefallenen Festplatte und das weitere Vorgehen, wenn der Standardpfad nicht greift und Daten extern extrahiert werden müssen.

Wenn jemand einen Datenrettungsdienst wegen eines ausgefallenen Arrays kontaktiert, bestimmt die Antwort auf die Frage „Welches RAID‑Level ist das?“ alles Weitere. RAIDZ1 und RAID 5 beruhen zwar auf demselben Grundprinzip — Parität über die Laufwerke zu verteilen, sodass ein einzelnes Laufwerk ausfallen kann, ohne dass Daten verloren gehen — doch ihr Verhalten unter Belastung unterscheidet sich erheblich. Diese Unterschiede werden besonders greifbar, sobald man ein degradiertes Array vor sich hat. Dieser Artikel beleuchtet, welche Auswirkungen die architektonischen Unterschiede auf Ausfallwahrscheinlichkeit, Wiederherstellungsaufwand und auf die jeweils geeigneten Tools für die Datenrettung (z. B. ZFS‑Utilities, mdadm) haben.