Kort svar: notera en hash när du skriver en fil, och jämför den senare. Om hasharna skiljer sig och inget har redigerat filen har byten ändrats under dig.
Inget annat hittar det här. En disk med tyst skada på sig klarar Första hjälpen, rapporterar frisk SMART och monteras perfekt.
Lagring är fysisk. Magnetiska domäner på en snurrande disk försvagas. Laddning läcker ut ur cellerna i flashminne, snabbare när det är varmt och ännu snabbare när enheten står utan ström länge. En kabel kan tappa en bit under överföringen. Inbyggd programvara har buggar.
Enheter rättar det mesta av detta själva, med felkorrigerande koder och genom att flytta sektorer de upptäcker håller på att gå sönder. Skadan som spelar roll är den del som slinker förbi: en läsning som returnerar andra byte än de som skrevs, och rapporterar att allt gick bra.
Namnet folk bråkar om. Vissa kallar det bitröta, vissa tyst datakorruption, vissa dataförsämring. För vår del är det samma sak: filen är annorlunda och inget sa till.
Det här är delen som är värd att förstå, eftersom den förklarar varför varje verktyg du skulle ta till är fel verktyg.
cp och Finder läser byte och skriver byte.
Om läsningen gav fel byte skriver de troget fel byte.Så den ärliga positionen är: din Mac har ingen mekanism som skulle säga till. Det första symtomet är en bild med ett band av skräp genom sig, ett arkiv som inte går att öppna eller en video som stannar halvvägs.
Ovanligt per fil, och inte ovanligt i en stor samling över lång tid, vilket är det fall en säkerhetskopia är till för. Två saker ökar risken märkbart:
Skälet till att det spelar större roll i en säkerhetskopia än på din arbetsdisk är att en arbetsfil öppnas, och en öppnad skadad fil är en skada du har upptäckt. En säkerhetskopia skrivs en gång och läses aldrig, vilket betyder att en skada i en säkerhetskopia upptäcks den dag du behöver säkerhetskopian.
Notera vad du skrev:
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txtFråga sedan, månader senare, om den fortfarande är densamma:
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'Allt som skrivs ut är en fil vars byte har ändrats. Om du inte har redigerat den är det ditt svar.
Två praktiska saker. Förvara hashfilen någon annanstans än på enheten den beskriver, annars förlorar du båda samtidigt. Och det här tar lika lång tid som att läsa hela enheten, så schemalägg det över natten.
Allt ovan är skälet till att appen finns i den form den har. Den lagrar varje del av en säkerhetskopia under hashen av dess innehåll, och läser sedan tillbaka säkerhetskopian enligt schema och kontrollerar varje del mot den hash den lagrades under.
En avvikelse är därför ett bevis: byten är inte de byte som skrevs, och det finns ingen tolkning där det är okej. En del som har raderats under säkerhetskopian rapporteras som saknad. Och poängen på huvudskärmen räknar bara det som har verifierats nyligen, vilket är varför den är lägre än folk väntar sig och varför det är poängen.
Att ha en andra plats spelar större roll här än någon annanstans på den här webbplatsen. En skada i en kopia är ett besvär när det finns två, och slutet för filen när det finns en.
Nej. Första hjälpen kontrollerar filsystemets struktur, inte innehållet i dina filer. En enhet med tyst skadade filer klarar den utan anmärkning, vilket är precis det som gör det här problemet till vad det är.
Inte för det här. SMART rapporterar fel som disken har märkt och rättat eller flyttat. Tyst korruption är just det den inte märkte. Värt att kolla ändå för en disk som håller på att gå sönder, vilket är ett annat och mer synligt problem.
Den kontrollsummerar sina egna metadata, inte din fildata. ZFS och Btrfs kontrollsummerar filinnehåll och kan reparera från en redundant kopia, och ingetdera finns som en vanlig startvolym eller extern volym i macOS. Det gapet är skälet till att en kontroll på applikationsnivå är värd att ha.
Tillräckligt ofta för att en dålig kopia hittas medan en bra kopia fortfarande finns. Varje kvartal är rimligt för ett arkiv; varje månad om det är den enda kopian av något oersättligt. Rätt svar är det du faktiskt inte hoppar över, vilket talar för att det ska vara automatiskt.
Nej. Verifiering säger att en kopia har blivit dålig. Den kan inte ge tillbaka filen. Att upptäcka är bara användbart när det finns en andra kopia att återställa från, vilket är hela argumentet för 3-2-1-regeln.
Relaterat: så kontrollerar du att en säkerhetskopia går att läsa, lagringsformatet, och 3-2-1-regeln.