Es gibt zwei mögliche Antworten, abhängig davon, was Sie unter "durch einen Festplattenfehler beschädigt" meinen.
Wenn Sie eine einfache Datenbeschädigung meinen
BTRFS behandelt dies selbst transparent für den Benutzer. Es prüft die Summen einschließlich der Daten in Momentaufnahmen intern und überprüft dann die Prüfsummen, während sie jeden Block liest. Es gibt jedoch einige Ausnahmen:
- Wenn das Volume mit der Option
nodatasumoder gemountet istnodatacow, haben Sie keine Prüfsummen für Datenblöcke. In den meisten Fällen sollten Sie diese Optionen nicht verwenden, daher sollte dies kein Problem sein. - Dateien, für die das
NOCOWAttribut gesetzt ist (Cin der Ausgabe deslsattrBefehls), werden ebenfalls nicht geprüft. Sie haben wahrscheinlich keine wirklich wichtigen Dateien mit diesem Attributsatz (für systemd-Journaldateien ist dies festgelegt, dies ist jedoch der Fall, es sei denn, Sie legen es manuell fest).
Wenn Sie nicht unerhebliche Zerstörung von Daten auf dem Datenträger meinen, wenn zu viele Geräte verloren gehen
Sie können sich dagegen nur schützen, wenn Sie irgendwo eine andere Kopie der Daten haben. Wenn Sie mehr Geräte verloren haben, als viele Speicherprofile für das Volume tolerieren können, sind Ihre Daten verschwunden, und nichts wird Sie zurückgewinnen, wenn Sie nicht aus einem Backup wiederhergestellt werden.
Über Ihren speziellen Fall
Die Probleme, über die Sie mit Senden / Empfangen sprechen, sind wahrscheinlich ein Nebeneffekt dieser nicht korrigierbaren Fehler, die von scrub gemeldet werden. Wenn BTRFS einen Fehler nicht transparent beheben kann (normalerweise, weil der Block mit einem Profil gespeichert wird, das keine Wiederherstellung durchführen kann, wie z. B. "single" oder "raid0"), wird ein E / A-Fehler zurückgegeben, der dazu führt, dass die Sendeoperation fehlschlägt. Sie erhalten also keine beschädigten Sicherungen, wenn Sie send / receive verwenden (und bei den meisten anderen Tools auch nicht). Jede gute Sicherungssoftware gibt einen Fehler aus, wenn eine Datei nicht gelesen werden kann ).
In diesem Fall klingt es so, als wären die nicht korrigierbaren Fehler ausschließlich in Daten enthalten, die ausschließlich Snapshots enthalten, oder die keine Snapshots sind. Sie können ziemlich leicht (wenn auch nicht sehr schnell) herausfinden, welche Dateien Probleme haben, indem Sie den Quelldatenträger irgendwo selbst mounten und den folgenden Befehl von dort aus ausführen, wo er gemountet ist:
find . -exec cat '{}' \; > /dev/null Dadurch wird versucht, jede Datei auf dem Volume zu lesen. In der Konsole werden alle Lesefehler mit dem Namen der Datei angezeigt. Dies ist möglicherweise sehr langsam, daher möchten Sie es möglicherweise parallelisieren, wenn Sie ein großes Volume haben.
Wenn Sie diese Dateien gefunden und bearbeitet haben, sollten Sie keine weiteren Probleme haben. Wenn Sie diese Fragen wieder passieren in naher Zukunft nach dem Fixieren sie sehen, sollten Sie Ihre Hardware in Überprüfung aussehen, als etwas leise verderblichen Daten vorhanden sind.