Respuesta corta: anota un hash al escribir un archivo y compáralo después. Si los hashes no coinciden y nada editó el archivo, los bytes cambiaron sin que lo supieras.
Nada más encuentra esto. Un disco con corrupción silenciosa pasa Primera ayuda, muestra un SMART sano y se monta perfectamente.
El almacenamiento es físico. Los dominios magnéticos de un disco giratorio se debilitan. La carga se escapa de las celdas de la memoria flash, más rápido cuando hace calor y más aún cuando el disco pasa mucho tiempo sin alimentación. Un cable puede perder un bit por el camino. El firmware tiene errores.
Los discos corrigen la mayor parte de esto por sí mismos, con códigos de corrección de errores y reubicando los sectores que detectan que se están estropeando. El daño que importa es el que se escapa a eso: una lectura que devuelve bytes distintos de los que se escribieron, e informa de que todo ha ido bien.
El nombre sobre el que se discute. Unos lo llaman bit rot, otros corrupción silenciosa de datos, otros degradación de datos. Para lo que nos ocupa son lo mismo: el archivo es distinto y nada lo dijo.
Esta es la parte que merece la pena entender, porque explica por qué cada herramienta a la que recurrirías es la herramienta equivocada.
cp y el Finder leen bytes y escriben bytes. Si la lectura devolvió bytes erróneos, escriben fielmente los bytes erróneos.Así que la postura honesta es: tu Mac no tiene ningún mecanismo que te lo diga. El primer síntoma es una foto con una franja de basura, un archivo comprimido que no se abre o un vídeo que se para a la mitad.
Rara por archivo, y no tan rara en una colección grande a lo largo de mucho tiempo, que es el caso para el que existe una copia. Dos cosas aumentan bastante las probabilidades:
La razón por la que importa más en una copia que en tu disco de trabajo es que un archivo de trabajo se abre, y un archivo dañado que se abre es un daño que has descubierto. Una copia se escribe una vez y nunca se lee, lo que significa que el daño en una copia se descubre el día que la necesitas.
Anota lo que escribiste:
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txt
Luego, meses después, pregunta si sigue siendo igual:
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'
Todo lo que se muestre es un archivo cuyos bytes han cambiado. Si no lo has editado, ahí tienes la respuesta.
Dos notas prácticas. Guarda el archivo de hashes en un sitio que no sea el disco que describe, o perderás los dos juntos. Y esto tarda lo que tarda leer el disco entero, así que prográmalo por la noche.
Todo lo anterior es la razón por la que la app existe tal como es. Guarda cada pieza de una copia bajo el hash de su contenido, y luego vuelve a leer la copia periódicamente y comprueba cada pieza contra el hash con el que se guardó.
Por tanto, una discrepancia es una prueba: los bytes no son los que se escribieron, y no hay interpretación en la que eso esté bien. Una pieza que se ha borrado por debajo de la copia se indica como ausente. Y la puntuación de la pantalla principal solo cuenta lo que se ha verificado recientemente, y por eso es más baja de lo que la gente espera, y de eso se trata.
Tener una segunda ubicación importa aquí más que en ningún otro sitio de esta web. El daño en una copia es una molestia cuando hay dos, y es el fin del archivo cuando hay una.
No. Primera ayuda comprueba la estructura del sistema de archivos, no el contenido de tus archivos. Un disco con archivos dañados en silencio la pasa sin problemas, que es justo lo que hace que este problema sea lo que es.
Para esto, no. SMART informa de los errores que el disco detectó y corrigió o reubicó. La corrupción silenciosa es justo lo que no detectó. Aun así, vale la pena revisarlo en un disco que está fallando, que es un problema distinto y mucho más visible.
Verifica sus propios metadatos, no los datos de tus archivos. ZFS y Btrfs verifican el contenido de los archivos y pueden repararlo desde una copia redundante, y ninguno está disponible como volumen de arranque o externo normal en macOS. Ese hueco es la razón por la que merece la pena una comprobación a nivel de aplicación.
Con la frecuencia suficiente para encontrar una copia mala mientras aún existe una buena. Cada trimestre es razonable para un archivo; cada mes si es la única copia de algo irreemplazable. La respuesta correcta es la que de verdad no te saltes, lo que aboga por que sea automática.
No. La verificación te dice que una copia se ha estropeado. No puede devolverte el archivo. Detectarlo solo sirve si hay una segunda copia desde la que restaurar, que es todo el argumento de la regla 3-2-1.
Relacionado: cómo comprobar que una copia se puede leer, el formato del repositorio y la regla 3-2-1.