Resposta curta: registre um hash quando gravar um arquivo, e compare depois. Se os hashes forem diferentes e nada editou o arquivo, os bytes mudaram sem você saber.
Nada mais encontra isso. Um disco com corrupção silenciosa passa no Primeiros Socorros, mostra SMART saudável e monta perfeitamente.
O armazenamento é físico. Domínios magnéticos num disco giratório enfraquecem. A carga vaza das células da memória flash, mais rápido quando está quente e mais rápido ainda quando o disco fica muito tempo sem energia. Um cabo pode perder um bit no caminho. Firmware tem bugs.
Os discos corrigem a maior parte disso sozinhos, com códigos de correção de erros e realocando setores que encontram estragando. A corrupção que importa é a parte que escapa disso: uma leitura que devolve bytes diferentes dos gravados, e informa sucesso.
O nome sobre o qual as pessoas discutem. Uns chamam de bit rot, outros de corrupção silenciosa de dados, outros de degradação de dados. Para o que nos interessa, é a mesma coisa: o arquivo está diferente e nada avisou.
Esta é a parte que vale entender, porque explica por que toda ferramenta que você usaria é a ferramenta errada.
cp e o Finder leem bytes e gravam bytes. Se a leitura devolveu bytes errados, eles gravam fielmente os bytes errados.Então a posição honesta é: o seu Mac não tem nenhum mecanismo que te avisaria. O primeiro sintoma é uma foto com uma faixa de lixo atravessando, um arquivo compactado que não abre, ou um vídeo que para no meio.
Raro por arquivo, e nada raro numa coleção grande ao longo de muito tempo, que é o caso para o qual um backup existe. Duas coisas aumentam as chances de forma notável:
O motivo de isso importar mais num backup do que no seu disco de trabalho é que um arquivo de trabalho é aberto, e um arquivo corrompido aberto é uma corrupção que você descobriu. Um backup é gravado uma vez e nunca lido, o que quer dizer que a corrupção num backup é descoberta no dia em que você precisa dele.
Registre o que você gravou:
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txtDepois, meses mais tarde, pergunte se ainda é o mesmo:
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'Qualquer coisa impressa é um arquivo cujos bytes mudaram. Se você não o editou, essa é a sua resposta.
Duas observações práticas. Guarde o arquivo de hashes num lugar que não seja o disco que ele descreve, ou você vai perder os dois juntos. E isso leva o tempo de ler o disco inteiro, então programe para a madrugada.
Tudo isso acima é o motivo de o app existir no formato em que existe. Ele guarda cada pedaço de um backup sob o hash do seu conteúdo, e depois lê o backup de volta de forma programada e confere cada pedaço com o hash sob o qual foi guardado.
Uma divergência é portanto uma prova: os bytes não são os bytes que foram gravados, e não há interpretação em que isso esteja tudo bem. Um pedaço que foi apagado por baixo do backup é informado como ausente. E a pontuação na tela principal só conta o que foi verificado recentemente, e é por isso que ela é mais baixa do que as pessoas esperam, e é justamente esse o ponto.
Ter um segundo local importa mais aqui do que em qualquer outro lugar deste site. Corrupção numa cópia é um incômodo quando existem duas, e é o fim do arquivo quando existe uma.
Não. O Primeiros Socorros confere a estrutura do sistema de arquivos, não o conteúdo dos seus arquivos. Um disco com arquivos corrompidos em silêncio passa sem problema, e é exatamente isso que faz deste problema o que ele é.
Não para isso. O SMART informa erros que o disco percebeu e corrigiu ou realocou. A corrupção silenciosa é justamente a que ele não percebeu. Ainda assim vale verificar em um disco que está falhando, o que é um problema diferente e mais visível.
Ele faz checksum dos próprios metadados, não dos dados dos seus arquivos. ZFS e Btrfs fazem checksum do conteúdo dos arquivos e conseguem reparar a partir de uma cópia redundante, e nenhum dos dois está disponível como volume normal de inicialização ou externo no macOS. Essa lacuna é o motivo de valer a pena ter uma verificação no nível do aplicativo.
Com frequência suficiente para que uma cópia ruim seja encontrada enquanto ainda existe uma cópia boa. Trimestralmente é razoável para um arquivo; mensalmente se for a única cópia de algo insubstituível. A resposta certa é a que você de fato não vai pular, o que é um argumento para ser automático.
Não. A verificação te diz que uma cópia estragou. Ela não consegue devolver o arquivo. A detecção só é útil quando existe uma segunda cópia de onde restaurar, que é todo o argumento da regra 3-2-1.
Relacionados: como conferir se um backup pode ser lido, o formato do repositório, e a regra 3-2-1.