Unraid Cache Corruption Errors: Daten bewahren und Ursache eingrenzen

Schritt für Schritt

1. Fehlermeldung und Ausgangszustand sichern

   Notieren Sie den genauen Wortlaut, Zeitpunkt und ersten beobachteten Auslöser. Exportieren Sie die Unraid-Diagnoseinformationen vor einem Neustart, soweit das System noch zugänglich ist. Erfassen Sie Poolname, Laufwerksseriennummern, Dateisystem und Redundanzprofil. Unterscheiden Sie Prüfsummenfehler, Ein-/Ausgabefehler, einen nur lesbar eingebundenen Pool und eine beschädigte einzelne Anwendungsdatei. Diese Zustände sind nicht gleichbedeutend. Dokumentieren Sie auch vorherige Stromausfälle, Kabeländerungen oder Updates. Eine klare Ausgangslage verhindert, dass nach mehreren ungeordneten Reparaturversuchen nur noch die letzten Symptome sichtbar bleiben.

2. Änderungen reduzieren und lesbare Daten retten

   Stoppen Sie schreibende Anwendungen möglichst über deren normale Steuerung. Ermitteln Sie, welche wichtigen Dateien ausschließlich auf dem betroffenen Pool liegen. Kopieren Sie zuerst einzigartige und aktuelle Inhalte auf einen gesunden unabhängigen Datenträger oder ein anderes System. Ein anderer Ordner auf demselben Pool ist kein geeignetes Rettungsziel. Protokollieren Sie Lesefehler und vermeiden Sie endlose Wiederholungen an einem verschwundenen oder mechanisch auffälligen Gerät. Wenn die Hardware instabil wird, sollten weitere Prüfungen bewusst abgewogen werden. Jede zusätzliche Belastung ist dann eine Entscheidung über die verbleibenden Wiederherstellungschancen.

3. Dateisystem und Schutzprofil bestimmen

   Prüfen Sie, ob der Pool Btrfs, ZFS oder ein anderes unterstütztes Dateisystem verwendet. Ermitteln Sie außerdem das tatsächliche Daten- und Metadatenprofil, statt Schutz aus der Zahl sichtbarer Laufwerke abzuleiten. Ein Dateisystem mit Prüfsummen kann Fehler erkennen, benötigt für eine mögliche automatische Korrektur aber eine gültige zusätzliche Datenkopie. Ein einzelnes Laufwerk stellt diese nicht allein durch die Verwendung von Btrfs oder ZFS bereit. Halten Sie Pooldiagnose und Array-Diagnose getrennt. Ähnlich aussehende Pfade oder Gerätenummern machen deren Werkzeuge nicht austauschbar.

4. Geeignete Diagnose statt blinder Reparatur wählen

   Lesen Sie den dokumentierten Ablauf für Dateisystem und installierte Unraid-Version. Prüfen Sie bei Btrfs die vorgesehenen Status- und Scrub-Möglichkeiten und deren Grenzen. Bei ZFS sind Poolzustand und zugehöriger Prüfablauf maßgeblich. XFS benötigt für bestimmte Prüfungen einen nicht eingebundenen Zustand. Verwenden Sie aggressive Reparaturoptionen nicht als Standardantwort auf eine Warnung. Insbesondere ein im Internet genannter Btrfs-Reparaturbefehl kann den Zustand verändern. Bei Unklarheit bewahren Sie Diagnose und Geräte unverändert und holen gezielte Hilfe mit den bereits gesicherten Informationen ein.

5. Hardwarepfad und Wiederherstellung gemeinsam bewerten

   Vergleichen Sie Laufwerkszustand und Systemprotokoll. Verbindungsabbrüche, steigende Transportfehler, Stromversorgung, Temperatur und Speicherinstabilität können relevant sein. Ein unauffälliger zusammenfassender SMART-Status schließt nicht jedes Problem aus. Prüfen Sie Veränderungen über die Zeit und deren Zusammenhang mit den Meldungen. Entscheiden Sie anschließend zwischen Wiederherstellung auf gesundem Speicher, Hardwareaustausch und einem ausdrücklich passenden Reparaturweg. Halten Sie Originalgeräte bis zur Abnahme erhalten. Nach der Rückkehr müssen Anwendungen ihre eigentlichen Datensätze öffnen können; ein wieder sichtbarer Ordner allein ist noch kein vollständiger Erfolg.

Ausführliche Anleitung

Array-Parität schützt den Pool nicht mit

Die Paritätslaufwerke des Unraid-Arrays beziehen sich auf dessen Datenlaufwerke. Ein separater SSD-Pool hat eine eigene Schutzstruktur. Auch zwei Paritätsplatten ändern nichts daran, dass eine aktuelle Datenbank ausschließlich auf einem einzelnen Pool-Laufwerk liegen kann. Prüfen Sie deshalb für jede wichtige Freigabe die tatsächliche Platzierung. Eine zusammengeführte Benutzerfreigabe kann verbergen, dass neu geschriebene Dateien noch nicht auf dem Array liegen. Erfassen Sie diese Inhalte ausdrücklich in Ihrer unabhängigen Sicherung und verlassen Sie sich nicht auf den Namen Cache.

Anwendungsfehler von Speicherfehlern trennen

Ein beschädigtes Docker-Image ist nicht automatisch gleichbedeutend mit einem vollständig beschädigten Pool. Umgekehrt behebt das Neuerstellen eines Images keinen defekten Datenpfad. Ermitteln Sie die konkret betroffene Datei und sichern Sie dauerhafte Anwendungsdaten separat. Datenbanken benötigen einen passenden konsistenten Export oder Wiederherstellungsweg. Bei virtuellen Maschinen sollten Sie nach stabilisiertem Hostspeicher zusätzlich das Gastbetriebssystem und wichtige Dateien prüfen. Ein erfolgreicher Start kann vorhandene Fehler in selten verwendeten Dokumenten oder Datenbanktabellen überdecken.

Warum Formatieren die Lage verschlechtert

Formatieren erstellt eine neue leere Dateisystemstruktur und ist keine Reparatur vorhandener Dateien. Die schnelle Rückkehr eines leeren eingebundenen Pools würde nur die Warnmeldung verändern, nicht Ihre Daten wiederbringen. Verwenden Sie diese Aktion erst, wenn ein bewusster Neuaufbau auf Grundlage einer geprüften Sicherung beschlossen wurde und die betroffenen Geräte eindeutig identifiziert sind. Bis dahin bleiben Originalzustand und Diagnoseinformationen wertvoll. Auch das Entfernen und Neuerstellen eines Pools sollte nicht als unverbindlicher Test behandelt werden.

Mover ist keine Wiederherstellungsstrategie

Mover verschiebt Dateien entsprechend den Freigabeeinstellungen, erzeugt aber keine historische unabhängige Sicherung. Ein beschädigter oder unvollständiger Bestand wird durch Verschieben nicht automatisch wieder korrekt. Prüfen Sie deshalb vor manuellen Aktionen Richtung, Ziel und Dateizustand. Vermeiden Sie außerdem unkontrollierte Kopien zwischen Benutzerfreigaben und deren zugrunde liegenden Laufwerkspfaden, weil beide dieselben Dateien darstellen können. Für Rettungskopien ist ein eindeutig getrenntes gesundes Ziel leichter überprüfbar. Nehmen Sie normale automatische Abläufe erst nach einer klaren Diagnose wieder auf.

Fehlerfreiheit anhand neuer Beobachtungen prüfen

Bewahren Sie ursprüngliche Zählerstände und Protokolle auf. Ein zurückgesetzter Fehlerzähler kann die Anzeige beruhigen, ohne die Ursache zu beseitigen. Vergleichen Sie spätere Werte nach normalen Arbeitsabläufen mit der dokumentierten Ausgangslage. Wenn neue Laufwerke an derselben Verbindung erneut Fehler zeigen, untersuchen Sie den gemeinsamen Pfad. Starten Sie Dienste schrittweise und prüfen Sie jeweils deren Daten. So lässt sich besser erkennen, ob eine bestimmte Last oder Anwendung den Fehler erneut sichtbar macht, statt sämtliche Arbeiten gleichzeitig wieder aufzunehmen.

Einen künftigen Rettungsweg vereinfachen

Nehmen Sie Pool-Daten, App-Konfigurationen und erforderliche Datenbanksicherungen in einen klaren Sicherungsplan auf. Prüfen Sie eine Wiederherstellung auf getrenntem Speicher und notieren Sie die verwendeten Versionen. Richten Sie erreichbare Warnmeldungen ein und planen Sie kontrolliertes Herunterfahren bei Stromproblemen. Die wichtigste Verbesserung nach dem Vorfall ist nicht nur eine ausgetauschte SSD. Sie besteht darin, dass die nächste Warnung früher auffällt und die einzige aktuelle Kopie wichtiger Inhalte nicht erneut auf dem betroffenen Gerät verbleibt.

Situationen im Vergleich

Häufige Fragen

Passende Anleitungen

• SSD für Unraid-Cache kaufen: Pool-Größe und Preise prüfen
• SSD für NAS-Cache kaufen: Kompatibilität und Preise prüfen
• Immich auf Unraid einrichten: Bereitstellung und App-Daten schützen
• 3-2-1-Backup: Kopien richtig planen und Wiederherstellung testen