Sichere Wiederherstellung beschädigter XFS- und Btrfs-Dateisysteme in Unraid

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.

Die Parität hilft hier nicht weiter. Die Paritätsplatte hält eine bitgenaue Kopie der Datensektoren, nicht jedoch eine Integritätsprüfung der Dateisystemmetadaten. Wenn das Journal oder der Superblock einer Datenplatte beschädigt ist, erhält die Parität diese Beschädigung unverändert. Die Wiederherstellung erfordert den direkten Einsatz der Dateisystem‑Reparaturwerkzeuge — xfs_repair für XFS‑Volumes und btrfs check für BTRFS — über das Unraid‑Terminal.

Situation	Dateisystem	Vorgehen	Erwartetes Ergebnis
Laufwerk nicht einbindbar, SMART unauffällig	XFS	Wartungsmodus → `xfs_repair /dev/sdXp1` → Neustart	✅ Laufwerk wird eingebunden; Daten intakt
`xfs_repair` schlägt fehl: dirty‑log‑Fehler	XFS	`xfs_repair -L /dev/sdXp1` (Journal auf NULL setzen)	⚠️ Laufwerk wird eingebunden; Dateien, die beim Absturz geöffnet waren, können unvollständig oder leer sein
Laufwerk nicht einbindbar, SMART unauffällig	BTRFS	`btrfs scrub` (bei gemountetem FS) → `btrfs check /dev/sdXp1` (nur lesend) → Fehler bewerten	✅ Geringfügige Fehler: Laufwerk lässt sich nach Check einhängen
`btrfs check` meldet Extent‑ oder Chunk‑Tree‑Fehler	BTRFS	Nicht `--repair` verwenden → Zuerst Dateiwiederherstellung mit RS RAID Retrieve	⚠️ Teilweise Wiederherstellung möglich; strukturelle Reparatur kann zu weiterem Datenverlust führen
Laufwerk nicht einbindbar, SMART meldet defekte Sektoren	XFS / BTRFS	RS RAID Retrieve → Vollanalyse → Wiederherstellung auf separater Festplatte → Austausch der defekten Platte einplanen	⚠️ Dateien sind wiederherstellbar; Hardware ist defekt — Reparatur nicht dauerhaft
Terminal‑Tools können Laufwerk nicht mounten; Dateien nach Reparatur fehlen	XFS / BTRFS	Datenträger an Windows‑PC anschließen → RS RAID Retrieve → Schnellscan oder Vollanalyse	✅ Dateiwiederherstellung auf Datei‑Ebene ohne Einbindung des Dateisystems
Auf dem nicht einbindbaren Laufwerk wurde „Format“ ausgeführt	Beliebig	Keine Wiederherstellungsoption — Parität spiegelt jetzt eine leere Platte	❌ Daten dauerhaft verloren

Wie Unraid pro Datenträger unabhängige Dateisysteme verwendet

Bei einem logischen Ausfall ist die Architektur von Unraid der entscheidende Faktor, um zu beurteilen, was beschädigt ist und was nicht.

Im Gegensatz zu RAID 5 oder RAID 6, bei denen ein Stripe sich über mehrere physische Laufwerke erstreckt, schreibt Unraid Dateien vollständig auf einzelne Datenträger. Jeder Datenträger ist ein eigenständiges Volume — formatiert als XFS oder BTRFS — und wird vom Betriebssystem unabhängig eingebunden. Die darüber liegende Array‑Schicht von Unraid aggregiert Freigaben (Shares) und verwaltet Paritätsaktualisierungen, während die darunterliegende Dateisystemebene Standard‑Linux‑Dateisysteme verwendet.

⚡

XFS

Standard-Dateisystem in Unraid

Für die Reparatur relevante Merkmale:

Journalgestützte Metadatenwiederherstellung (Journaling)
Für die Reparatur muss das Laufwerk ausgehängt (unmounted) sein
In Unraid: erfordert den Wartungsmodus
Hauptwerkzeug: xfs_repair
Bei Log-Korruption ist das Flag -L erforderlich (destruktiv)

🌿

BTRFS

Optional in Unraid

Für die Reparatur relevante Merkmale:

Copy-on-Write (COW); integrierte Prüfsummen für Daten und Metadaten
Prüfung kann auf einem eingehängten Volume ausgeführt werden
Der Reparaturmodus (--repair) arbeitet aggressiv — mit Vorsicht verwenden
Hauptwerkzeuge: btrfs check, btrfs scrub
Wiederherstellung von Subvolumes möglich, selbst bei teilweiser Beschädigung

Die praktische Konsequenz dieser Architektur: Eine Dateisystembeschädigung auf Laufwerk 3 hat keine Auswirkungen auf die Dateisysteme von Laufwerk 1, Laufwerk 2 oder anderen Laufwerken. Die Daten jedes Laufwerks sind isoliert. Sie reparieren ein einzelnes Volume, nicht das gesamte Array. Die Ausnahme ist das Paritätslaufwerk — es besitzt kein Dateisystem und darf niemals mit Dateisystem-Reparaturwerkzeugen behandelt werden.

Paritätslaufwerk hat kein Dateisystem — führen Sie niemals xfs_repair oder btrfs check darauf aus.

Das Paritätslaufwerk speichert XOR-Daten über feste Sektor-Offsets. Es besitzt keine Partitionstabelle, die von Dateisystemwerkzeugen erkannt würde; der Versuch, es als Dateisystem zu reparieren, zerstört die Paritätsdaten und macht das gesamte Array ungeschützt. Identifizieren Sie Ihr Paritätslaufwerk im WebGUI, bevor Sie ein Terminal öffnen.

Ursachen für Dateisystemkorruption in Unraid

Dateisystemkorruption in Unraid lässt sich nahezu immer auf eine von drei Hauptursachen zurückführen. Die korrekte Identifikation der zugrundeliegenden Ursache bestimmt die gewählte Reparaturstrategie und beeinflusst die Erfolgsaussichten bei der Datenrettung und Wiederherstellung.

🔌

Unsauberes Herunterfahren

Bei einem Stromausfall oder einem erzwungenen Neustart, während das Speicher‑Array aktiv ist, bleiben laufende Schreibvorgänge unvollständig und werden nicht festgeschrieben. Bei Journaling‑Dateisystemen enthält das Journal dadurch unvollständige Transaktionen. Beim nächsten Einhängen erkennt das Dateisystem die Inkonsistenz und verweigert das Mounten. Dies ist die häufigste Ursache.

🧠

Fehlerhafter Arbeitsspeicher (RAM)

ECC‑Speicher (ECC‑RAM) ist in den meisten Unraid‑Installationen nicht standardmäßig vorhanden. Ein einzelner Bit‑Flip in einem Schreibpuffer kann Dateisystem‑Metadaten — Verzeichniseinträge, Inode‑Tabellen oder den Superblock — so beschädigen, dass die Symptome einem Stromausfall gleichen, sich jedoch schwerer verhindern lassen.

💾

Sektorfehler auf Datenträgern

Umlagerungen (reallocated) oder schwebende Sektoren in den SMART‑Daten eines Laufwerks weisen auf Bereiche hin, die das Laufwerk nicht zuverlässig lesen oder beschreiben kann. Treffen Metadatenstrukturen auf solche Sektoren, führt das auch ohne Stromereignis zu Dateisystemkorruption. Zeigt ein Laufwerk eine Dateisystembeschädigung bei gleichzeitig nicht‑null SMART‑Fehlerzählern, deutet dies in der Regel auf ein zugrundeliegendes Hardwareproblem hin.

Vor dem Einsatz eines Reparatur‑Tools — zuerst SMART prüfen:

Unraid WebGUI öffnen → Reiter Main → das betroffene Laufwerk anklicken → SMART‑Bericht.
Wenn Reallocated_Sector_Ct, Current_Pending_Sector oder Offline_Uncorrectable ungleich null sind, kann die Dateisystemreparatur zwar kurzfristig erfolgreich sein, die Hardware weist jedoch einen Ausfall auf. Unabhängig vom Reparaturergebnis sollte der Austausch des Laufwerks (Festplatte/SSD) eingeplant werden.
Sind die SMART‑Werte unauffällig, handelt es sich bei der Korruption wahrscheinlich um ein einmaliges Ereignis infolge eines Stromausfalls oder eines Softwarefehlers, und die Reparatur ist eher langfristig wirksam.

Die Schaltfläche „Format“: Was sie tatsächlich bewirkt und warum man sie nicht drücken sollte

Wenn ein Laufwerk als nicht einhängbar (Unmountable) markiert wird, zeigt die Unraid-Weboberfläche (WebGUI) neben den Diagnose-Schaltflächen die Option „Format“ an. Für Anwender, die mit der Handhabung der Parität in Unraid nicht vertraut sind, erzeugt das eine gefährliche Fehlannahme: Man könnte denken, durch Drücken von „Format“ werde das Laufwerk wiederhergestellt und die verlorenen Dateien würden automatisch anhand der Paritätsdaten rekonstruiert.

☠️

Formatieren stellt Daten nicht wieder her. Es löscht sie dauerhaft.

Das Ausführen von „Format“ bei einem nicht einhängbaren Laufwerk löscht das Dateisystem vollständig und erzeugt ein neues, leeres Volume. Die Parität wird anschließend gegen dieses nun leere Laufwerk neu berechnet. Die ursprünglichen Daten sind damit unwiederbringlich verloren — nicht beschädigt, nicht wiederherstellbar, nicht mehr vorhanden. Die Parität spiegelt dann korrekt ein leeres Laufwerk wider, sodass jeder nachfolgende Versuch der Datenwiederherstellung aussichtslos ist.

Dies ist neben Hardwarefehlern das häufigste Szenario für Datenverlust bei Unraid und beruht vollständig auf Benutzerhandlungen. Die Daten, die sich vor dem Formatieren auf dem Laufwerk befanden, lassen sich in den meisten Fällen mit den in diesem Artikel beschriebenen Datenrettungs-Tools wiederherstellen.

Die korrekte Vorgehensweise bei einem nicht einhängbaren Laufwerk: zuerst diagnostizieren, danach reparieren; formatieren nur als allerletzte Maßnahme — und ausschließlich nachdem alle Daten bereits an einen anderen Speicherort wiederhergestellt wurden.

Reparatur eines nicht einhängbaren XFS-Datenträgers in Unraid: xfs_repair Schritt für Schritt

Das Dienstprogramm xfs_repair setzt voraus, dass das zu reparierende XFS-Dateisystem vollständig ausgehängt ist, bevor es ausgeführt wird. In einem laufenden Unraid-Array sind alle Datenlaufwerke eingebunden. Um ein bestimmtes Laufwerk zur Reparatur auszuhängen, ohne die Shares komplett zu stoppen, muss Unraid in den Wartungsmodus versetzt werden — ein Startmodus, bei dem das Array hochgefahren wird, ohne dass Freigaben gemountet sind oder Datenträger aktiv verwendet werden.

Schritt 1: Array im Wartungsmodus starten

Öffnen Sie in der Unraid-Weboberfläche (Web-GUI) die Seite Main. Bevor Sie auf Start klicken, aktivieren Sie das Kontrollkästchen Maintenance Mode, das unter den Steuerungen zum Starten des Arrays angezeigt wird. Klicken Sie auf Start. Das Array wird gestartet, aber keine Datenträger werden in die Shares eingebunden. Dies ist der erforderliche Zustand für xfs_repair (XFS‑Reparatur).

Unraid 7.0 und neuer: Verwenden Sie zuerst die Reparatur‑Schaltflächen in der Web‑GUI.

Ab Unraid 7.0 stellt die Web‑GUI in der Laufwerksübersicht direkt die Schaltflächen CHECK und FIX zur Verfügung. Diese führen xfs_repair automatisch mit den passenden Optionen zur XFS‑Reparatur aus. Wenn Ihre Version diese Funktion unterstützt, probieren Sie zunächst den GUI‑Weg, bevor Sie ein Terminal öffnen — das Ergebnis ist identisch, die Oberfläche übernimmt jedoch Wartungsmodus und die Auswahl der Gerätepfade für Sie.

Schritt 2: Den korrekten Gerätepfad ermitteln

Dieser Schritt beugt einem häufigen und gravierenden Fehler vor. In Unraid verfügt jede Datenplatte über zwei Gerätepfade:

/dev/mdXp1 — das MD‑(Array‑)Gerät, das von der Array‑Schicht von Unraid verwaltet wird. Verwenden Sie diesen Pfad nicht für xfs_repair.
/dev/sdXp1 — die rohe Festplattenpartition, direkter Hardwarepfad. Verwenden Sie diesen Pfad.

Um zu ermitteln, welches /dev/sdX der zu reparierenden Festplatte entspricht, öffnen Sie ein Terminal (über die WebGUI: Tools → Terminal, oder per SSH) und führen Sie aus:

	# List disks with their Unraid slot assignments
	ls -la /dev/disk/by-id/

Vergleichen Sie die im WebGUI‑SMART‑Report angezeigte Seriennummer mit dem Symlink in /dev/disk/by-id/, um den Gerätepfad (/dev/sdX) vor dem Fortfahren eindeutig zu bestätigen.

Schritt 3: xfs_repair ausführen — Standarddurchlauf

	# Ersetzen Sie sdX durch Ihren tatsächlichen Gerätebezeichner (z. B. sdb, sdc)
	xfs_repair
	/dev/sdXp1

xfs_repair durchläuft mehrere Phasen und prüft Inodes, Verzeichnisse sowie die Freiraummap des XFS‑Dateisystems. Bei intaktem Journal werden nicht abgeschlossene Transaktionen erneut eingespielt (Journal‑Wiederherstellung) und das Programm beendet sich mit einer Zusammenfassung. Wird die Reparatur ohne schwerwiegende Fehler abgeschlossen, versuchen Sie, die Partition durch einen Neustart ohne Wartungsmodus erneut zu mounten.

Schritt 4: Wenn xfs_repair bei einem dirty log fehlschlägt — das -L-Flag

Wenn die Reparatur mit einer Meldung wie „ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed“ abbricht und sich weigert fortzufahren, ist das XFS-Journal nicht lesbar. In diesem Fall bleibt nur, das Journal mit dem -L-Flag zu nullen.

Die Option -L verwirft das Journal — was das bedeutet

Das Zurücksetzen des XFS‑Logs zwingt xfs_repair dazu, ausstehende Metadaten‑Transaktionen zu verwerfen, die noch nicht auf die Festplatte geschrieben wurden. In der Praxis bedeutet das, dass Dateien, die zum Zeitpunkt des Absturzes gerade geschrieben wurden, teilweise verloren gehen oder als 0‑Byte‑Dateien angezeigt werden können. Dateien, die vor dem Fehlerereignis vollständig geschrieben waren, bleiben davon unberührt.

Die Option -L darf nur angewendet werden, wenn ein regulärer Reparaturversuch mit xfs_repair fehlgeschlagen ist. Sie sollte nicht als erster Schritt bei der Wiederherstellung des XFS‑Dateisystems eingesetzt werden.

	# Force repair by zeroing the dirty log
	# Use only after standard xfs_repair has failed
	xfs_repair
	-L
	/dev/sdXp1

Schritt 5: Reparatur verifizieren

Nach erfolgreicher Reparatur führen Sie xfs_repair erneut im Nur‑Prüfmodus (Option -n) aus, um sicherzustellen, dass keine weiteren Inkonsistenzen im XFS‑Dateisystem vorliegen:

	# Dry-run check — makes no changes, reports remaining issues
	xfs_repair
	-n
	/dev/sdXp1

Wenn der Prüflauf keine Probleme meldet, starten Sie normal neu (nicht im Wartungsmodus). Die Partition sollte sich einhängen (mounten) und das zugehörige Share wieder verfügbar sein. Führen Sie im Anschluss eine nicht‑korrigierende Paritätsprüfung durch, um die Paritätsintegrität zu bestätigen.

✓ Erwartete Ausgabe nach erfolgreicher Reparatur

xfs_repair gibt Abschlusszeilen für die Phasen 1 bis 7 aus und beendet sich mit: „done“. In den Phasen 3–7 dürfen keine Fehler erscheinen. Alle während der Reparatur nach /lost+found verschobenen Dateien sind nach dem Einhängen der Festplatte dort zugänglich — sie können an ihre ursprünglichen Speicherorte zurückverschoben werden, sofern der ursprüngliche Pfad bekannt ist.

Reparatur eines beschädigten Btrfs‑Volumes in Unraid

Btrfs‑Korruption in Unraid tritt seltener auf als XFS‑Korruption, teilweise weil das Dateisystem Btrfs die Copy‑on‑Write‑Semantik (CoW) verwendet — es überschreibt vorhandene Daten niemals, sondern schreibt neue Versionen von Blöcken zunächst in freie Speicherbereiche. Dadurch ist es widerstandsfähiger gegenüber unvollständigen Schreibvorgängen. Allerdings können Metadaten trotzdem beschädigt werden, und das Vorgehen zur Reparatur unterscheidet sich in mehreren wichtigen Punkten von dem bei XFS.

Schritt 1: Mit btrfs scrub beginnen — nicht mit btrfs check

Bevor Sie Reparaturmaßnahmen durchführen, führen Sie auf dem eingehängten Unraid‑Volume einen Scrub durch. Im Gegensatz zu xfs_repair kann btrfs scrub laufen, während das Dateisystem gemountet ist. Der Scrub prüft die Checksummen aller Daten‑ und Metadatenblöcke und meldet Abweichungen. Auf einem Single‑Disk‑Unraid‑Volume ohne BTRFS‑RAID kann scrub Fehler nicht automatisch beheben — es existieren keine redundanten Kopien — identifiziert jedoch exakt die beschädigten Blöcke. Diese Informationen sind wichtig für die weitere Fehlerbehebung und die Entscheidung über eine Reparaturstrategie. Starten Sie das Array normal (nicht im Wartungsmodus) und öffnen Sie ein Terminal:

	# Replace /mnt/diskX with the actual Unraid disk mount path
	btrfs scrub start
	/mnt/diskX
	# Monitor progress
	btrfs scrub status
	/mnt/diskX

Wenn der Scrub ohne Fehler abgeschlossen wird, ist die Festplatte wahrscheinlich gesund und der „Unmountable“-Status könnte ein vorübergehendes Ereignis gewesen sein. Starten Sie das System neu und prüfen Sie, ob das Laufwerk anschließend normal eingehängt wird.

Schritt 2: btrfs check im schreibgeschützten Modus ausführen

Wenn btrfs scrub Fehler meldet oder das Laufwerk nach einem Scrub-Versuch weiterhin nicht mountbar ist, mit btrfs check fortfahren. Zuerst das Array stoppen, damit das Laufwerk ausgehängt werden kann, und btrfs check im schreibgeschützten Modus ausführen, um das Ausmaß der Dateisystem-Beschädigung zu beurteilen, bevor Reparaturmaßnahmen gestartet werden:

	# Stop array first, then check without making changes
	btrfs check
	/dev/sdXp1

Die Ausgabe sorgfältig prüfen. btrfs check listet konkrete Baumfehler und verwaiste Einträge auf. Kleinere Inkonsistenzen — verwaiste Inodes oder fehlerhafte Rückverweise auf die Wurzel — lassen sich in der Regel gefahrlos reparieren. Fehler im Extent-Baum oder im Chunk-Baum deuten auf tiefergehende strukturelle Schäden hin; eine Wiederherstellung im Reparaturmodus (repair) kann in solchen Fällen unvollständig bleiben.

Schritt 3: Reparaturmodus — mit Vorsicht verwenden

btrfs check –repair kann zu weiterem Datenverlust führen

Im Gegensatz zu xfs_repair, das für den routinemäßigen Einsatz ausgelegt ist, warnen die BTRFS‑Entwickler ausdrücklich davor, den Modus --repair ohne Rücksprache mit einem Entwickler oder ohne vorheriges Festplatten‑Image zu verwenden. Bei schwerer Beschädigung des Extent‑Trees kann der Reparaturmodus Dateien löschen, die er als verwaist einstuft, anstatt sie zu rekonstruieren.

Wenn die schreibgeschützte Prüfung Fehler im Extent‑Tree anzeigt und sich unersetzbare Daten auf dem Datenträger befinden, überspringen Sie den Reparaturmodus und führen Sie vor jeglichen strukturellen Reparaturmaßnahmen zunächst eine Dateiwiederherstellung mit RS RAID Retrieve durch.

Bei geringfügigen, gut eingrenzbaren Beschädigungen — Free‑Space‑Cache‑Fehler, verwaiste Inodes, fehlerhafte Root‑Rückverweise — ist der Reparaturmodus in der Regel unkritisch:

	# Only for minor, well-scoped corruption
	# Image the disk first if data is critical
	btrfs check
	--repair
	/dev/sdXp1

Schritt 4: Einzelne Subvolumes wiederherstellen

Wenn der oberste Btrfs‑Wurzelbaum beschädigt ist, die Daten‑Subvolumes jedoch intakt sind, kann es möglich sein, ein bestimmtes Subvolume direkt einzubinden (mounten) und die Daten daraus zu kopieren, ohne den übergeordneten Baum zu reparieren. Diese Methode wird häufig zur Datenrettung bei beschädigten Btrfs‑Dateisystemen eingesetzt und eignet sich, um schnell Daten zu sichern.

	# List subvolumes on a partially readable volume
	btrfs subvolume list
	/mnt/diskX
	# Mount a specific subvolume by ID if the default mount fails
	mount
	-o subvolid=256
	/dev/sdXp1 /mnt/recovery_point

Wenn sich ein Subvolume erfolgreich einbinden lässt, sollten die Daten umgehend auf ein intaktes Laufwerk kopiert bzw. gesichert werden, bevor weitere Reparaturmaßnahmen am beschädigten Volume erfolgen.

Wenn Terminal-Tools versagen: Wiederherstellung von Dateien einer beschädigten Unraid-Festplatte mit RS RAID Retrieve

Die Werkzeuge xfs_repair und btrfs check arbeiten auf Ebene der Dateisystemstrukturen — sie versuchen, das Volume wieder einhängbar zu machen. Ist dies bei Unraid-Systemen aufgrund starker Metadatenkorruption nicht möglich, oder führt eine Reparatur zwar zu einem einhängbaren Volume, bleiben Dateien jedoch fehlen oder sind leer, ist der nächste Schritt eine dateibasierte Datenrettung aus den Rohdaten der Festplatte.

Hier setzt RS RAID Retrieve an. Das Programm liest sektorweise Rohdaten, umgeht beschädigte Dateisystemstrukturen und rekonstruiert Verzeichnisbäume sowie Dateiinhalte aus den zugrundeliegenden Allokationstabellen. Es unterstützt sowohl XFS als auch BTRFS, die Windows nicht nativ einhängen kann — deshalb ist der Standard-Workflow die Arbeit an einem Windows‑PC mit extern angeschlossener Festplatte.

Was RS RAID Retrieve mit einer beschädigten Unraid‑Festplatte macht

Das Programm identifiziert die Unraid‑Array‑Struktur anhand der Festplattenmetadaten, stellt das logische Volume wieder her und scannt anschließend das Dateisystem auf Sektorebene. Für die Unraid‑Datenrettung und RAID‑Wiederherstellung — insbesondere bei XFS‑Dateisystemen — liest das Tool Allokationsdaten direkt aus und kann so häufig Dateiinhalte und ursprüngliche Verzeichnispfade rekonstruieren, selbst wenn xfs_repair Dateien nach /lost+found verschoben hat oder die Metadaten zu stark beschädigt sind, um das Dateisystem einzubinden.

RS Raid Retrieve

Datenwiederherstellung von beschädigten RAID-ArraysWiederherstellung jeder Art von RAID-Array

Herunterladen

Verfügbar für: Windows, macOS, Linux

Unraid-Server herunterfahren und betroffene Festplatte ausbauen

Fahren Sie den Server ordnungsgemäß herunter, falls er noch erreichbar ist. Schließen Sie die beschädigte Festplatte an einen Windows‑PC an — nach Möglichkeit per direkter SATA‑Verbindung. Schließen Sie außerdem die übrigen Array‑Datenträger und das Paritätslaufwerk an; RS RAID Retrieve nutzt diese zur Rekonstruktion der vollständigen Array‑Konfiguration und zur korrekten Zuordnung der Rolle jeder Festplatte innerhalb der Unraid‑Struktur für die RAID‑Wiederherstellung und Datenrettung.

RS RAID Retrieve starten — automatische Array-Erkennung

Beim Start durchsucht das Programm alle angeschlossenen Laufwerke, liest aus jedem die Unraid‑Metadaten aus und stellt die RAID‑Array‑Konfiguration automatisch wieder her. Die beschädigte Festplatte erscheint in der Laufwerksliste neben den intakten Mitgliedern. Windows weist XFS‑ oder BTRFS‑Volumes keine Laufwerksbuchstaben zu; dies ist erwartetes Verhalten und stellt kein Verbindungsproblem dar.

Scan‑Typ je nach Beschädigungsgrad auswählen

Klicken Sie in der Laufwerksverwaltung mit der rechten Maustaste auf das rekonstruierte Array oder das einzelne Laufwerk und wählen Sie Öffnen. Bei der Datenrettung von Dateisystemen, bei denen Partitionstabelle und Superblock intakt sind, genügt ein Schnellscan; dieser zeigt den Verzeichnisbaum an und hebt wiederherstellbare Dateien hervor. Ist der Superblock beschädigt oder liefert der Schnellscan einen leeren Verzeichnisbaum, führen Sie eine Vollanalyse durch — diese führt einen sektorweisen Signaturscan durch und kann Dateien auch dann rekonstruieren, wenn Verzeichnismetadaten fehlen; Dateinamen und -pfade bleiben dabei möglicherweise nicht erhalten.

Dateien vor der Wiederherstellung in der Vorschau anzeigen

RS RAID Retrieve ermöglicht eine Dateivorschau vor der RAID-Wiederherstellung, ohne zunächst etwas auf den Datenträger zu schreiben. Nutzen Sie die Vorschau, um zu überprüfen, ob wiederhergestellte Dateien intakt sind — öffnen Sie stichprobenartig Dokumente, Bilder und Archive direkt im Vorschaufenster. Dateien, die in der Vorschau korrekt angezeigt werden, lassen sich in der Regel erfolgreich wiederherstellen. Werden Dateien in der Vorschau leer oder beschädigt dargestellt, ist bei der Datenrettung unabhängig vom eingesetzten Tool nicht mit verwertbaren Inhalten zu rechnen.

Wiederhergestellte Dateien auf einen separaten, gesunden Zielort kopieren

Wählen Sie die Dateien und Verzeichnisse aus, die wiederhergestellt werden sollen, klicken Sie auf Wiederherstellung und geben Sie einen Ausgabepfad auf einem separaten, gesunden Datenträger an. Stellen Sie keine Dateien auf das Quelllaufwerk oder auf ein Laufwerk wieder her, das sich derzeit im Unraid‑Array befindet. Überprüfen Sie nach dem Kopiervorgang stichprobenartig eine Auswahl der wiederhergestellten Dateien, bevor die Wiederherstellung beziehungsweise die Datenrettung als abgeschlossen gilt.

Wiederherstellungsergebnisse nach Art der Datenkorruption

✅Journalkorruption / unsauberes Herunterfahren

Das am besten wiederherstellbare Szenario. Dateizuordnungsstrukturen sind in der Regel intakt. RS RAID Retrieve kann die vollständige Verzeichnisstruktur rekonstruieren und Dateien mit ursprünglichen Dateinamen und -pfaden wiederherstellen. Ein Schnellscan (Fast Scan) ist in der Regel ausreichend.

⚠️

Teilweise Beschädigung der Metadaten

Verzeichnisbäume können unvollständig sein. In der Wiederherstellungsansicht erscheinen einige Dateien ohne Namen. Die Dateiinhalte sind häufig intakt, auch wenn die Metadaten beschädigt sind. Die vollständige Analyse (Full Analysis) stellt mehr Dateien wieder her, geht jedoch zulasten der ursprünglichen Verzeichnisstruktur in den betroffenen Bereichen.

❌

Superblock und Extent‑Baum zerstört

Wenn die Festplatte nach dem Zustand „Unmountable“ formatiert wurde oder physische Sektorschäden sowohl den primären als auch den Sicherungs‑Superblock zerstört haben, ist eine Wiederherstellung auf Dateiebene nicht möglich. Dieses Ergebnis ist bei rein logischen Fehlern selten, tritt jedoch häufig auf, wenn die „Format“-Schaltfläche betätigt wurde oder die Festplatte bereits fortgeschrittene Hardware‑Schäden aufweist.

Beschädigungen des Dateisystems unter Unraid sind in den meisten Fällen wiederherstellbar — vorausgesetzt, die korrekte Vorgehensweise wird eingehalten und die „Format“-Schaltfläche wird nicht gedrückt, bevor die Daten gesichert sind. Der Entscheidungsweg ist eindeutig:

Ein logischer Fehler bedeutet nicht zwangsläufig, dass die Parität ungültig ist — dennoch darf ihr nicht blind vertraut werden.

Nach einer Dateisystemreparatur enthält das Paritätslaufwerk weiterhin das XOR der Sektoren der Festplatte — einschließlich jener Sektoren, die vor der Reparatur beschädigt waren. Sobald die Festplatte repariert ist und fehlerfrei eingehängt wird, sollte ein nicht‑korrigierender Paritäts‑Check durchgeführt werden, um eventuelle Inkonsistenzen zu identifizieren. Werden Fehler festgestellt, ist anschließend ein korrigierender Paritäts‑Check auszuführen, um die Parität mit dem aktuellen Zustand der Festplatte abzugleichen. Dies muss erfolgen, bevor das Array wieder in den normalen Produktivbetrieb zurückkehrt.

Häufig gestellte Fragen

Das bedeutet in der Regel, dass die zugrunde liegende Hardware fehlerhafte Daten schneller schreibt, als die Reparatur sie beheben kann. xfs_repair hat die zum Zeitpunkt des Laufs festgestellten Inkonsistenzen in den Metadaten korrigiert, aber wenn das Laufwerk über pending (vorübergehend markierte) oder neu zugewiesene Sektoren verfügt, landen neue Schreibvorgänge während des Neustartvorgangs — beim Journal‑Replay oder beim Einhängen des Dateisystems — auf fehlerhaften Blöcken und führen die Beschädigung erneut ein. Eine erfolgreiche Ausgabe von xfs_repair bedeutet nicht, dass das Laufwerk gesund ist; sie besagt lediglich, dass das Dateisystem in diesem Moment konsistent war. Tritt dieses Problem auf, führen Sie xfs_repair nicht ein zweites Mal aus. Bauen Sie das Laufwerk aus, schließen Sie es an einen Windows‑PC an und verwenden Sie RS RAID Retrieve, um die Daten zu extrahieren, bevor das Laufwerk weiter degradiert. Ersetzen Sie anschließend die Hardware.

Dies ist ein Copy-on-Write-bedingter Nebeneffekt unter bestimmten Bedingungen. BTRFS überschreibt vorhandene Blöcke nicht – es schreibt neue Versionen in freien Speicher und aktualisiert anschließend den Metadatenbaum, damit er auf die neuen Blöcke zeigt. Wird die Stromversorgung zwischen dem Schreiben der Daten und dem Commit der Metadaten unterbrochen, liegen die neuen Daten zwar physisch auf dem Medium, der Verzeichnisbaum verweist jedoch weiterhin auf die alte Position – die möglicherweise teilweise überschrieben wurde oder nie vollständig geschrieben wurde. Die betroffenen Dateien erscheinen deshalb leer bzw. mit null Bytes, weil die Metadaten nicht aktualisiert wurden. Das Ausführen von btrfs check im Nur‑Lese‑Modus zeigt in diesen Bereichen typischerweise verwaiste Inodes. Die Vollanalyse von RS RAID Retrieve kann die tatsächlichen Datenblöcke anhand ihrer BTRFS‑Prüfsummen auffinden, selbst wenn der Verzeichnisbaum sie nicht mehr korrekt referenziert.

Ja — und bei jeder Festplatte mit einem oder mehreren SMART‑Fehlern ist das zwingend, nicht optional. Verwende ddrescue mit einer Map‑Datei, damit unterbrochene Sitzungen fortgesetzt werden können: ddrescue -d -r3 /dev/sdXp1 /path/to/image.img /path/to/map.log. Sobald du das Image erstellt hast, führe xfs_repair auf der Image‑Datei und nicht auf der Live‑Festplatte aus: xfs_repair /path/to/image.img. Sollte die Reparatur ein schlechteres Ergebnis liefern als erwartet, hast du weiterhin die sektorgenaue Originalkopie als Ausgangsbasis. Eine Einschränkung: Das Ziel für das Image muss eine Festplatte sein, die groß genug ist, um die vollständige rohe Größe der Quellpartition aufzunehmen — nicht nur den tatsächlich genutzten Platz.

Teilweise. xfs_repair verschiebt Dateien, deren Verzeichniseinträge verloren gegangen sind, nach /lost+found und benennt sie nach ihrer Inode‑Nummer. Wenn Sie sich an ungefähre Dateigrößen, Erstellungsdaten oder Inhaltstypen erinnern, können Sie die Kandidaten eingrenzen, indem Sie mit stat die Inode‑Metadaten prüfen und mit file den Inhaltstyp aus dem binären Header identifizieren — file /mnt/diskX/lost+found/123456789 zeigt z. B., ob eine Inode ein JPEG, einen Video‑Container, ein komprimiertes Archiv usw. enthält. Bei Mediendateien lassen sich die meisten anhand des Inhalts erkennen und entsprechend umbenennen. Bei Datenbanken oder Anwendungsdaten ohne lesbaren Header ist die Identifikation deutlich schwieriger und erfordert ggf. den Abgleich von Dateigrößen mit bekannten Backups oder das Auswerten von Anwendungslogs, die ursprüngliche Dateinamen protokolliert haben.