Wie können wir sicherstellen, dass ein schreibgeschützter Snapshot nicht aufgrund eines Festplattenfehlers beschädigt ist?
Besteht die einzige Möglichkeit darin, die Prüfsummen übereinander zu berechnen und für eine spätere Prüfung zu speichern, oder erledigt BTRFS das selbstständig?
Begründung
Ich sichere meine Snapshots regelmäßig, um einem möglichen Festplattenausfall vorzubeugen. Vor einigen Tagen konnte ich keinen btrfs send | btrfs receivebestimmten Snapshot erstellen. Als ich ihn löschte, verliefen die restlichen Vorgänge normal. Außerdem btrfs scrubheißt es, es gebe einige nicht korrigierbare Fehler. Das brachte mich auf die Idee, dass meine Snapshots auf der primären Festplatte möglicherweise beschädigt wurden, bevor ich sie auf der externen Festplatte gesichert habe, und wenn ich mir dessen nicht bewusst bin, hätte ich am Ende bereits beschädigte Backups auf der externen Festplatte.
Das ist es, was ich verhindern möchte. Ich möchte sicher sein, dass ein Snapshot, den ich sichern kann, nicht beschädigt ist.
Antwort1
Abhängig davon, was Sie mit „durch einen Festplattenfehler beschädigt“ meinen, gibt es zwei mögliche Antworten.
Wenn Sie eine einfache Beschädigung ruhender Daten meinen
BTRFS erledigt dies selbst, für den Benutzer transparent. Es berechnet intern die Prüfsummen aller Daten, einschließlich der Daten in Snapshots, und überprüft dann die Prüfsummen beim Lesen jedes Blocks. Es gibt jedoch ein paar Ausnahmen:
nodatasumWenn das Volume mit den Optionen oder gemountet wirdnodatacow, erfolgt keine Prüfsummenberechnung der Datenblöcke. In den meisten Fällen sollten Sie diese Optionen nicht mounten, daher sollte dies kein Problem darstellen.- Alle Dateien, für die das
NOCOWAttribut gesetzt ist (Cin der Ausgabe deslsattrBefehls), werden ebenfalls nicht geprüft. Es ist unwahrscheinlich, dass Sie wirklich wichtige Dateien mit diesem Attribut haben (in systemd-Journaldateien ist es gesetzt, aber das ist auch schon alles, sofern Sie es nicht manuell setzen).
Wenn Sie eine nicht triviale Zerstörung von Daten auf dem Datenträger aufgrund des Verlusts zu vieler Geräte meinen
Sie können sich dagegen nicht schützen, außer indem Sie irgendwo eine weitere Kopie der Daten aufbewahren. Wenn Sie mehr Geräte verloren haben, als die Speicherprofile für das Volume vertragen, sind Ihre Daten praktisch verloren und Sie können sie nur durch Wiederherstellen aus einer Sicherung wiederherstellen.
Zu Ihrem konkreten Fall
Die Probleme, die Sie mit Senden/Empfangen ansprechen, sind wahrscheinlich eine Nebenwirkung der von Scrub gemeldeten nicht korrigierbaren Fehler. Wenn BTRFS einen Fehler nicht transparent beheben kann (normalerweise, weil der Block mit einem Profil gespeichert ist, das keine Wiederherstellung durchführen kann, wie Single oder Raid0), gibt es einen E/A-Fehler zurück, der dazu führt, dass der Sendevorgang fehlschlägt. Wenn Sie Senden/Empfangen verwenden, haben Sie also keine bereits beschädigten Backups (und eigentlich auch nicht mit den meisten anderen Tools, jede gute Backup-Software gibt einen Fehler aus, wenn sie eine Datei nicht lesen kann).
In diesem Fall scheint es, als ob die nicht korrigierbaren Fehler ausschließlich in Daten liegen, die ausschließlich in Snapshots enthalten sind oder von denen kein Snapshot erstellt wird. Sie können ziemlich einfach (wenn auch nicht sehr schnell) herausfinden, welche Dateien Probleme haben, indem Sie das Quellvolume irgendwo separat mounten und den folgenden Befehl von dort ausführen, wo es gemountet ist:
find . -exec cat '{}' \; > /dev/null
Dabei wird versucht, jede Datei auf dem Datenträger zu lesen. Alle Lesefehler werden auf der Konsole angezeigt, wobei der Name der Datei in der Fehlermeldung enthalten ist. Dies ist möglicherweise sehr langsam, daher sollten Sie es parallelisieren, wenn Sie einen großen Datenträger haben.
Sobald Sie diese Dateien gefunden und bearbeitet haben, sollten Sie keine weiteren Probleme mehr haben. Wenn diese Probleme nach der Behebung in naher Zukunft erneut auftreten, sollten Sie Ihre Hardware überprüfen, daetwasbeschädigt unbemerkt Daten.