Kurz gesagt: Halte beim Schreiben einer Datei einen Hash fest und vergleiche ihn später. Wenn sich die Hashes unterscheiden und niemand die Datei bearbeitet hat, haben sich die Bytes unter dir verändert.
Nichts anderes findet das. Ein Laufwerk mit stiller Beschädigung besteht Erste Hilfe, meldet gesunde SMART-Werte und wird einwandfrei eingebunden.
Speicher ist physisch. Magnetische Bereiche auf einer drehenden Platte werden schwächer. Ladung entweicht aus den Zellen von Flash-Speicher, schneller wenn es warm ist und noch schneller, wenn das Laufwerk lange ohne Strom liegt. Ein Kabel kann bei der Übertragung ein Bit verlieren. Firmware hat Fehler.
Laufwerke korrigieren das meiste davon selbst, mit fehlerkorrigierenden Codes und indem sie Sektoren umlagern, die sie schlecht werden sehen. Die Beschädigung, die zählt, ist der Teil, der daran vorbeikommt: ein Lesevorgang, der andere Bytes liefert als die geschriebenen und Erfolg meldet.
Über den Namen wird gestritten. Manche nennen es Bitfäule, manche stille Datenbeschädigung, manche Datenverfall. Für unsere Zwecke ist es dasselbe: Die Datei ist anders, und nichts hat es gesagt.
Diesen Teil lohnt es sich zu verstehen, denn er erklärt, warum jedes Werkzeug, zu dem du greifen würdest, das falsche ist.
cp und der Finder lesen Bytes und schreiben Bytes. Wenn beim Lesen falsche Bytes kamen, schreiben sie getreu die falschen Bytes.Die ehrliche Lage ist also: Dein Mac hat keinen Mechanismus, der es dir sagen würde. Das erste Symptom ist ein Foto mit einem Streifen Datenmüll, ein Archiv, das sich nicht öffnen lässt, oder ein Video, das mittendrin abbricht.
Selten pro Datei und nicht selten über eine große Sammlung und lange Zeit, und genau dafür ist ein Backup da. Zwei Dinge erhöhen die Wahrscheinlichkeit merklich:
Warum es in einem Backup mehr zählt als auf deinem Arbeitslaufwerk: Eine Arbeitsdatei wird geöffnet, und eine geöffnete beschädigte Datei ist eine Beschädigung, die du entdeckt hast. Ein Backup wird einmal geschrieben und nie gelesen, also wird eine Beschädigung in einem Backup an dem Tag entdeckt, an dem du das Backup brauchst.
Halte fest, was du geschrieben hast:
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txtDann, Monate später, frag, ob es noch dasselbe ist:
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'Alles, was ausgegeben wird, ist eine Datei, deren Bytes sich verändert haben. Wenn du sie nicht bearbeitet hast, ist das deine Antwort.
Zwei praktische Hinweise. Bewahr die Hash-Datei woanders auf als auf dem Laufwerk, das sie beschreibt, sonst verlierst du beide zusammen. Und das dauert so lange, wie das ganze Laufwerk zu lesen, also plane es über Nacht.
All das ist der Grund, warum die App so gebaut ist, wie sie ist. Sie speichert jedes Stück eines Backups unter dem Hash seines Inhalts, liest das Backup dann regelmäßig zurück und vergleicht jedes Stück mit dem Hash, unter dem es gespeichert wurde.
Eine Abweichung ist daher ein Beweis: Die Bytes sind nicht die Bytes, die geschrieben wurden, und es gibt keine Deutung, in der das in Ordnung ist. Ein Stück, das unter dem Backup gelöscht wurde, wird als fehlend gemeldet. Und die Punktzahl auf dem Hauptbildschirm zählt nur, was kürzlich geprüft wurde, deshalb ist sie niedriger, als viele erwarten, und genau darum geht es.
Ein zweiter Speicherort ist hier wichtiger als irgendwo sonst auf dieser Website. Eine Beschädigung in einer Kopie ist ärgerlich, wenn es zwei gibt, und das Ende der Datei, wenn es nur eine gibt.
Nein. Erste Hilfe prüft die Struktur des Dateisystems, nicht den Inhalt deiner Dateien. Ein Laufwerk mit still beschädigten Dateien besteht sie problemlos, und genau das macht dieses Problem aus.
Dafür nicht. SMART meldet Fehler, die die Festplatte bemerkt und korrigiert oder verlagert hat. Stille Datenbeschädigung ist genau das, was sie nicht bemerkt hat. Trotzdem lohnt sich ein Blick darauf bei einer Festplatte, die ausfällt. Das ist ein anderes, deutlich sichtbareres Problem.
Es prüft seine eigenen Metadaten, nicht deine Dateidaten. ZFS und Btrfs prüfen Dateiinhalte und können aus einer redundanten Kopie reparieren, und keins von beiden steht als normales macOS-Start- oder externes Volume zur Verfügung. Wegen dieser Lücke lohnt sich eine Prüfung auf Anwendungsebene.
Oft genug, dass eine schlechte Kopie gefunden wird, solange noch eine gute existiert. Vierteljährlich ist für ein Archiv vernünftig, monatlich, wenn es die einzige Kopie von etwas Unersetzlichem ist. Die richtige Antwort ist, was du wirklich nicht auslassen wirst, und das spricht dafür, es zu automatisieren.
Nein. Eine Prüfung sagt dir, dass eine Kopie schlecht geworden ist. Sie kann dir die Datei nicht zurückgeben. Erkennen nützt nur, wenn es eine zweite Kopie gibt, aus der du wiederherstellen kannst, und das ist das ganze Argument für die 3-2-1-Regel.
Siehe auch: prüfen, ob ein Backup lesbar ist, das Repository-Format und die 3-2-1-Regel.