In breve: registra un hash quando scrivi un file, e confrontalo più tardi. Se gli hash sono diversi e nessuno ha modificato il file, i byte sono cambiati a tua insaputa.
Nient'altro lo trova. Un disco con una corruzione silenziosa supera S.O.S., riporta uno SMART sano e si monta perfettamente.
L'archiviazione è fisica. I domini magnetici su un disco rotante si indeboliscono. La carica sfugge dalle celle della memoria flash, più in fretta quando fa caldo e ancora più in fretta quando l'unità resta a lungo senza alimentazione. Un cavo può perdere un bit durante il trasferimento. Il firmware ha bug.
Le unità correggono da sole quasi tutto questo, con codici di correzione degli errori e spostando i settori che trovano in degrado. La corruzione che conta è la parte che sfugge a tutto ciò: una lettura che restituisce byte diversi da quelli scritti, e segnala successo.
Il nome su cui si discute. Alcuni lo chiamano bit rot, altri corruzione silenziosa dei dati, altri degrado dei dati. Per noi sono la stessa cosa: il file è diverso e niente lo ha detto.
Questa è la parte che vale la pena capire, perché spiega perché ogni strumento a cui penseresti è quello sbagliato.
cp e il Finder leggono byte e scrivono byte. Se la lettura ha restituito byte sbagliati, scrivono fedelmente i byte sbagliati.Quindi la posizione onesta è: il tuo Mac non ha alcun meccanismo che te lo direbbe. Il primo sintomo è una foto attraversata da una banda di disturbi, un archivio che non si apre o un video che si ferma a metà.
Raro per singolo file, e non raro su una grande raccolta nell'arco di molto tempo, che è proprio il caso per cui esiste un backup. Due cose aumentano sensibilmente le probabilità:
Il motivo per cui conta di più in un backup che sul disco di lavoro è che un file di lavoro viene aperto, e un file danneggiato aperto è un danno che hai scoperto. Un backup viene scritto una volta e mai letto, il che significa che un danno in un backup si scopre il giorno in cui ti serve il backup.
Registra ciò che hai scritto:
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txtPoi, mesi dopo, chiedi se è ancora lo stesso:
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'Qualsiasi riga stampata è un file i cui byte sono cambiati. Se non l'hai modificato, ecco la tua risposta.
Due note pratiche. Conserva il file degli hash in un posto diverso dall'unità che descrive, altrimenti li perderai insieme. E l'operazione dura quanto la lettura dell'intera unità, quindi programmala di notte.
Tutto quanto sopra è il motivo per cui l'app esiste nella forma che ha. Salva ogni pezzo di un backup sotto l'hash del suo contenuto, poi rilegge il backup a intervalli regolari e controlla ogni pezzo con l'hash con cui è stato salvato.
Una discrepanza è quindi una prova: i byte non sono quelli che sono stati scritti, e non c'è interpretazione in cui vada bene. Un pezzo eliminato sotto al backup viene segnalato come mancante. E il punteggio nella schermata principale conta solo ciò che è stato verificato di recente, ed è per questo che è più basso di quanto ci si aspetti, ed è proprio questo il punto.
Avere una seconda posizione conta qui più che in qualsiasi altro punto di questo sito. Un danno in una copia è un fastidio quando le copie sono due, ed è la fine del file quando ce n'è una sola.
No. S.O.S. controlla la struttura del file system, non il contenuto dei tuoi file. Un'unità con file danneggiati in silenzio lo supera senza problemi, ed è esattamente questo che rende il problema quello che è.
Non per questo. SMART segnala gli errori che il disco ha notato e corretto o riallocato. La corruzione silenziosa è proprio quella che non ha notato. Conviene comunque controllarlo per un disco che si sta guastando, un problema diverso e più visibile.
Fa il checksum dei propri metadati, non dei dati dei tuoi file. ZFS e Btrfs fanno il checksum del contenuto dei file e possono riparare da una copia ridondante, ma nessuno dei due è disponibile come normale volume di avvio o esterno su macOS. È per questa lacuna che vale la pena avere un controllo a livello di applicazione.
Abbastanza spesso da trovare una copia guasta mentre ne esiste ancora una buona. Ogni tre mesi è ragionevole per un archivio; ogni mese se è l'unica copia di qualcosa di insostituibile. La risposta giusta è quella che davvero non salterai, il che fa pendere per un controllo automatico.
No. La verifica ti dice che una copia si è guastata. Non può restituirti il file. Il rilevamento è utile solo quando c'è una seconda copia da cui ripristinare, ed è tutto l'argomento a favore della regola 3-2-1.
Vedi anche: come verificare che un backup sia leggibile, il formato del repository e la regola 3-2-1.