Kort antwoord: leg een hash vast als je een bestand schrijft, en vergelijk die later. Verschillen de hashes en heeft niets het bestand bewerkt, dan zijn de bytes onder je handen veranderd.
Niets anders vindt dit. Een schijf met stille beschadiging doorstaat EHBO, meldt een gezonde SMART en wordt perfect gekoppeld.
Opslag is fysiek. Magnetische domeinen op een draaiende schijf verzwakken. Lading lekt uit de cellen van flashgeheugen, sneller als het warm is en nog sneller als de schijf lang zonder stroom ligt. Een kabel kan onderweg een bit laten vallen. Firmware heeft fouten.
Schijven corrigeren het meeste hiervan zelf, met foutcorrigerende codes en door sectoren te verplaatsen die slecht worden. De beschadiging die telt, is het deel dat daar langs komt: een leesactie die andere bytes teruggeeft dan er werden geschreven, en succes meldt.
De naam waar mensen over twisten. Sommigen noemen het bitrot, anderen stille gegevensbeschadiging, weer anderen gegevensdegradatie. Voor ons is het hetzelfde: het bestand is anders en niets zei het.
Dit is het deel dat de moeite waard is om te begrijpen, want het verklaart waarom elke tool waar je naar zou grijpen de verkeerde is.
cp en Finder lezen bytes en schrijven bytes. Gaf het lezen verkeerde bytes terug, dan schrijven ze keurig de verkeerde bytes.De eerlijke positie is dus: je Mac heeft geen mechanisme dat het je zou vertellen. Het eerste symptoom is een foto met een band rommel erdoorheen, een archief dat niet opent, of een video die halverwege stopt.
Zeldzaam per bestand, en niet zeldzaam in een grote verzameling over lange tijd, en dat is waar een backup voor is. Twee dingen verhogen de kans merkbaar:
Het is in een backup belangrijker dan op je werkschijf omdat een werkbestand wordt geopend, en een geopend beschadigd bestand is een beschadiging die je hebt ontdekt. Een backup wordt één keer geschreven en nooit gelezen, dus beschadiging in een backup ontdek je op de dag dat je de backup nodig hebt.
Leg vast wat je schreef:
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txtVraag dan, maanden later, of het nog steeds hetzelfde is:
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'Alles wat wordt getoond, is een bestand waarvan de bytes zijn veranderd. Heb je het niet bewerkt, dan is dat je antwoord.
Twee praktische opmerkingen. Bewaar het hashbestand ergens anders dan op de schijf die het beschrijft, anders verlies je ze samen. En dit duurt zo lang als het lezen van de hele schijf, dus plan het voor 's nachts.
Alles hierboven is de reden dat de app bestaat in de vorm die hij heeft. Hij bewaart elk stuk van een backup onder de hash van de inhoud, leest de backup daarna volgens schema terug en controleert elk stuk tegen de hash waaronder het is opgeslagen.
Een verschil is daarom een bewijs: de bytes zijn niet de bytes die werden geschreven, en er is geen uitleg waarin dat in orde is. Een stuk dat onder de backup is verwijderd, wordt als ontbrekend gemeld. En de score op het hoofdscherm telt alleen wat recent is gecontroleerd, en daarom is hij lager dan mensen verwachten, en dat is precies de bedoeling.
Een tweede locatie is hier belangrijker dan waar dan ook op deze site. Beschadiging in één kopie is lastig als er twee zijn, en het einde van het bestand als er één is.
Nee. EHBO controleert de structuur van het bestandssysteem, niet de inhoud van je bestanden. Een schijf met stilletjes beschadigde bestanden komt er probleemloos doorheen, en dat is precies wat dit probleem tot dit probleem maakt.
Niet hiervoor. SMART meldt fouten die de schijf zelf heeft opgemerkt en gecorrigeerd of verplaatst. Stille corruptie is juist wat de schijf niet opmerkte. Wel de moeite om te controleren bij een schijf die het begeeft, maar dat is een ander en beter zichtbaar probleem.
Het controleert zijn eigen metadata met checksums, niet je bestandsgegevens. ZFS en Btrfs controleren de inhoud van bestanden en kunnen herstellen vanuit een redundante kopie, en geen van beide is beschikbaar als gewoon opstart- of extern volume op macOS. Door dat gat is een controle op appniveau de moeite waard.
Vaak genoeg dat een slechte kopie wordt gevonden terwijl er nog een goede bestaat. Elk kwartaal is redelijk voor een archief; maandelijks als het de enige kopie is van iets onvervangbaars. Het juiste antwoord is wat je echt niet overslaat, en dat pleit ervoor het automatisch te doen.
Nee. Controleren vertelt je dat een kopie slecht is geworden. Het kan het bestand niet teruggeven. Ontdekken heeft alleen zin als er een tweede kopie is om van terug te zetten, en dat is het hele argument voor de 3-2-1-regel.
Verwant: controleren of een backup leesbaar is, het repositoryformaat, en de 3-2-1-regel.