Woran erkennt man, dass ein RAID-Scrub neue Schäden entdeckt?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Ein Scrub erkennt neue Schäden, wenn die Fehleranzahl zwischen den Durchläufen steigt, Reparaturen am selben Gerät wiederholt werden oder zuvor saubere Daten nicht mehr korrigierbar sind. Ein einzelner isolierter reparierter Block ist nicht dasselbe wie ein sich verschlechterndes Muster.

Die sicherste Interpretation ergibt sich aus dem Vergleich abgeschlossener Scrub-Berichte, Laufwerksfehlern und betroffenen Dateien, anstatt auf eine einzelne alarmierende Zahl zu reagieren. Diese Anleitung trennt normale Korrekturen von sich anhäufenden Schäden und zeigt, wann die routinemäßige Wartung gestoppt und zuerst die Daten geschützt werden sollten.

Eine steigende Fehleranzahl ist die deutlichste Warnung

Der wichtigste Vergleich ist nicht, ob ein Scrub Fehler meldet, sondern ob der nächste abgeschlossene Scrub mehr Prüfsummen-, Paritäts-, Medien- oder unkorrigierbare Fehler meldet. Eine stabile Anzahl nach der Reparatur kann ein altes Ereignis widerspiegeln. Eine steigende Anzahl bedeutet, dass der Speicherpfad weiterhin fehlerhafte Lesevorgänge oder fehlerhafte Daten produziert.

Notieren Sie nach jedem Durchlauf Startzeit, Abschlusszeit, reparierte Bytes, Anzahl unkorrigierbarer Fehler sowie Lese-, Schreib- oder Prüfsummen-Zähler pro Gerät. Praktische Erklärungen zu Scrubbing und stiller Korruption zeigen, warum ein vollständiges Lesen Schäden aufdecken kann, die gewöhnliche Arbeitslasten monatelang nicht berührt haben.

Wiederholte Reparaturen am selben Laufwerk erfordern Aufmerksamkeit

Ein redundantes Dateisystem kann einen beschädigten Block von einer anderen Kopie reparieren und den Pool dennoch online lassen. Die Warnung tritt auf, wenn spätere Scrubs neue Blöcke auf demselben physischen Laufwerk reparieren, besonders wenn das Laufwerk auch anstehende, neu zugewiesene oder unkorrigierbare Sektoren ansammelt.

Löschen Sie die Zähler nicht und vergessen Sie das Ereignis nicht. Speichern Sie zuerst die Laufwerks-Seriennummer, den SMART-Snapshot und das Scrub-Ergebnis. Führen Sie dann nur einen langen Selbsttest des Laufwerks durch, wenn das Array weiterhin redundant und ansprechbar ist. Wiederholte Korrekturen sind ein Hinweis darauf, das Mitglied, Kabel, den Einschub, den Strompfad und den Controller zu untersuchen, und kein Beweis dafür, dass das Dateisystem die Ursache behoben hat.

Unkorrigierbare Dateien ändern die Priorität

Ein unkorrigierbares Ergebnis bedeutet, dass die Redundanz für mindestens einen Block keine verifizierte Kopie erzeugen konnte. In diesem Fall ist ein weiterer Scrub nicht automatisch der nächste Schritt. Identifizieren Sie die benannten Dateien, kopieren Sie lesbare kritische Daten an einen anderen Ort und sichern Sie Protokolle, bevor Sie Topologieänderungen vornehmen.

Ein praxisnaher Scrub mit unkorrigierbaren Daten verdeutlicht den Unterschied zwischen korrigierten Metadaten und Dateien, die noch aus dem Backup wiederhergestellt werden mussten. Das nützliche Signal ist nicht nur die große Rohfehlersumme, sondern ob ein sauberer Folge-Durchlauf ohne neue Fehler abgeschlossen werden kann.

Dasselbe logische Gebiet fällt erneut aus ist nicht normal

Fehler, die an demselben Stripe, Blockbereich oder derselben Datei wiederkehren, können auf eine dauerhaft unlesbare Region oder einen beschädigten Paritätszustand hinweisen. Fehler, die sich verschieben, können auf eine breitere Medienverschlechterung, instabilen Speicher, ein Verbindungsproblem oder Strominstabilität hindeuten. Speichern Sie genaue Offsets, wenn die Plattform diese anzeigt.

Vermeiden Sie es, Reparaturen über Millionen von Fehlern hinweg zu erzwingen, ohne den zuerst betroffenen Bereich zu verstehen. Ein großer Paritätsfehler-Cluster kann von einem früheren I/O-Fehler stammen und spätere Vergleiche verfälschen, daher sind die erste fehlerhafte Position und das vorausgehende Ereignis wichtig.

Neue Verbindungs- oder I/O-Fehler während des Scrubs sind relevant

Ein Scrub erzeugt anhaltende Lesevorgänge und kann ein marginales Kabel, Backplane, Stromanschluss, USB-Bridge oder Controller-Pfad aufdecken. Beobachten Sie das Systemprotokoll während des Scrubs. Link-Resets, Befehls-Timeouts, Geräte-Trennungen und CRC-Fehler sind stärkere Warnungen als ein langsamer Prozentsatz allein.

Wenn Kommunikationsfehler zunehmen, aber die Medien-Sektor-Indikatoren stabil bleiben, pausieren Sie, bevor Sie das Laufwerk verurteilen. Stecken Sie eine Verbindung nach der anderen neu ein oder tauschen Sie sie aus, bewahren Sie die Seriennummer-zu-Einschub-Zuordnung auf, setzen Sie die Fehlerbasis zurück und wiederholen Sie einen kontrollierten Lesevorgang. Ein Fehler, der am Pfad bleibt, benötigt eine andere Reparatur als ein Fehler, der dem Laufwerk folgt.

Ein Scrub, der nicht abgeschlossen werden kann, ist ebenfalls ein Ergebnis

Ein Scrub, der wiederholt pausiert, neu startet oder an fast derselben Stelle stoppt, dauert nicht einfach nur lange. Bestätigen Sie zuerst, dass geplante Jobs, Herunterfahren oder ein anderer Resilver-Vorgang ihn nicht unterbrechen. Korrigieren Sie dann den Stopp-Punkt mit Geräteprotokollen und Latenzzeiten pro Laufwerk.

Ein geplanter Prozess sollte eine stabile Basislinie für Dauer und Durchsatz haben. Hinweise zum Interpretieren von Scrub-Ausgaben sind nützlich, da Fortschritt, reparierte Bytes und der Endstatus zusammen gelesen werden müssen; die verstrichene Zeit allein beweist keinen Schaden.

Verwenden Sie eine Trendtabelle, bevor Sie entscheiden

Eine kurze Historie verhindert, dass ein lauter einzelner Durchlauf zu einem riskanten Austausch führt. Bewahren Sie die untenstehenden Beobachtungen mindestens für den letzten sauberen Durchlauf und jeden Durchlauf nach dem ersten Fehler auf.

Beobachtung Üblicherweise überwachen Jetzt eskalieren
Reparierte Blöcke Ein Ereignis, nächster Scrub sauber Neue Reparaturen bei späteren Scrubs
Unkorrigierbare Daten Keine Beliebige benannte Datei oder permanenter Fehler
Gerätezähler Stabil nach Reset Lese-/Schreib-/Prüfsummen-Zähler steigen weiter
Systemprotokoll Keine Resets oder Timeouts Wiederholte Trennungen, Resets oder I/O-Fehler
Abschluss Beendet nahe der normalen Basislinie Stoppt wiederholt im gleichen Bereich

Wenn zwei oder mehr Eskalationssignale zusammen auftreten, reduzieren Sie Schreibvorgänge, bestätigen Sie das Backup und diagnostizieren Sie den betroffenen Hardwarepfad, bevor Sie einen weiteren vollständigen Scrub starten.

FAQ

Sollte ich Fehlerzähler nach einem reparierten Scrub zurücksetzen?

Setzen Sie sie nur zurück, nachdem Sie den Bericht gespeichert und das physische Laufwerk identifiziert haben. Eine zurückgesetzte Basislinie kann helfen, ein Wiederauftreten zu erkennen, aber das Zurücksetzen vorab zerstört den Vergleich, der zeigt, ob der Schaden neu ist.

Bedeutet ein Prüfsummenfehler, dass das Laufwerk ersetzt werden muss?

Nicht alleinstehend. Ein korrigierter Fehler kann von Medien, Speicher, Verkabelung oder einer früheren Unterbrechung stammen. Ein Austausch wird eher gerechtfertigt, wenn nach Überprüfung des Pfads neue Fehler am selben Laufwerk mit derselben Seriennummer auftreten.

Kann starker Anwendungsverkehr Prüfsummenschäden verursachen?

Starker Verkehr kann den Scrub verlangsamen und schwache Hardware aufdecken, aber eine legitime Arbeitslast sollte keine verifizierten Inhaltsabweichungen erzeugen. Behandeln Sie neue Prüfsummenfehler als Ereignis zur Speicherintegrität, nicht als normale Leistungsnebenwirkung.

Die Entscheidungsgrenze

Bewerten Sie das Scrub-Ergebnis als sich verschlechternden Schaden, wenn Fehler über abgeschlossene Durchläufe zunehmen, Reparaturen an einem Mitglied wiederkehren, unkorrigierbare Dateien auftreten oder derselbe Hardwarepfad sich ständig zurücksetzt. Schützen Sie die Daten, bevor Sie den Stress wiederholen.

Support & Tipps

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.