El bitrot, como la idea de que un solo bit volteado no se detecta, es probablemente un mito basado en una lectura errónea de la especificación común de los discos duros de 1 bit ilegible cada 1014 bits (o a veces 1015). Esa es una estadística que se refiere a los bits que no se pueden leer en absoluto. Quizá signifique que hay un sector ilegible de 512 bytes cada 400 PB. Puede que los fabricantes de discos duros se refieran simplemente al sector ilegible estándar que aparece en SMART. La idea de que un solo bit puede voltear y de alguna manera deslizarse a través de cada capa de comprobación de paridad de hardware y software es bastante inverosímil y nunca he visto ningún dato empírico o un solo caso documentado de ello.

Pero hay otros tipos de putrefacción de datos que pueden ocurrir en varios niveles. Pero para qué hablar de teorías y anécdotas. Somos guardianes de datos, ¿no?

Tomé 70 TB de datos (unos 300.000 archivos) y almacené dos copias en conjuntos separados de discos duros. Uno de los conjuntos fue almacenado en frío, el otro conjunto se utilizó activamente y se movió/copió entre diferentes unidades y sistemas de archivos. El conjunto almacenado en frío se giraba una vez al año para evitar que el líquido de los rodamientos se asentara. El conjunto activo se movía/copiaba en su totalidad unas 5 veces en total (digamos, 350 TB de transferencias). Toda la RAM era no ECC. Las unidades eran modelos de consumo de una mezcla de todas las marcas. El conjunto activo pasó un año en ZFS bajo FreeBSD (cuando me sentía particularmente paranoico sobre el bitrot y quería los CRC de los archivos), el resto del tiempo en NTFS bajo Windows 7.

Después de 7 años, hice una comprobación MD5 en ambos conjuntos de datos. Había 12 archivos que no coincidían.

Archivo 1 – Archivo de datos del juego, 2 KB. Tamaño idéntico, contenido significativamente diferente, y la copia activa tenía una fecha más reciente. Parece un archivo de caché del juego y fue objeto de modificación por el propio juego. No hay daños.

Archivo 2 – Archivo de copia de seguridad de Steam, 832 MB. Tamaño idéntico, contenido significativamente diferente, y la copia activa era 2 horas más reciente. Parece que era simplemente una copia de seguridad más reciente que hice. No hay daños.

Archivo 3 – Vídeo, 399 MB. La copia de seguridad tiene los primeros 64K sustituidos por nulos, y no se reproduce. Tamaño y fecha idénticos.

Archivo 4 – Vídeo, 19 MB. La copia de seguridad tiene los primeros 64K sustituidos por una sección de un texto que estuvo en mi portapapeles, y no se reproduce. Tamaño y fecha idénticos.

Archivo 5 – Vídeo, 11,7 GB. Los archivos difieren en 232 bytes en el offset 9.693.699.010. Ambos contienen datos comprimidos indistinguibles. Ambos vídeos se reproducen.

Archivo 6 – Vídeo, 2,9 GB. Los archivos difieren en 251 bytes en el offset 1.039.651.777. Ambos contienen datos comprimidos indistinguibles. Ambos vídeos se reproducen. Tamaño y fecha idénticos.

Archivo 7 – Vídeo, 9,4 GB. Los archivos difieren en 47 bytes en el offset 3.976.714.817. Ambos contienen datos comprimidos indistinguibles. Ambos vídeos se reproducen. Tamaño y fecha idénticos.

Archivo 8 – Vídeo, 4,6 GB. Los archivos difieren en 232 bytes en el offset 627,313,318. Ambos contienen datos comprimidos indistinguibles. Ambos vídeos se reproducen. Tamaño y fecha idénticos.

Archivo 9 – Vídeo, 6,2 GB. Los archivos difieren en 104 bytes en el offset 1.496.829.600. Ambos contienen datos comprimidos indistinguibles. Ambos vídeos se reproducen. Tamaño y fecha idénticos.

Archivo 10 – Vídeo, 8,5 GB. Los archivos difieren en 512 bytes en el offset 6.517.833.728. Ambos contienen datos comprimidos indistinguibles. Ambos vídeos se reproducen. Tamaño y fecha idénticos.

Archivo 11 – Vídeo, 1 GB. La copia activa tiene 54.784 bytes corruptos en el offset 684.589.056. Los datos corruptos incluyen grandes trozos de nulos, bytes repetidos y secciones de texto que incluyen «root_dataset», «sync_bplist», «vdev» y «zpool create» que parecen estar relacionados con ZFS. Tamaño y fecha idénticos.

Archivo 12 – Vídeo, 817 MB. La copia activa tiene 43.520 bytes corruptos en el offset 418.578.432. Los datos corruptos son del mismo tipo que los encontrados en el archivo 11. Idéntico tamaño y fecha.

Así que tenemos 4 tipos de corrupción de datos aquí.

Los archivos 1 y 2 no tienen realmente corrupción, simplemente no coinciden porque han sido modificados.

Los archivos 3 y 4 tenían exactamente 65.536 bytes reemplazados al principio del archivo con aparentemente algunas cosas al azar de la memoria. No tengo una explicación para esto, pero debe haber sucedido cuando se hizo la copia de seguridad porque la versión activa seguía siendo buena. Podría haber sido porque usé SuperCopier, que probablemente no está completamente libre de errores. Una vez vi que sobrescribía un archivo porque el nombre largo de un archivo en la cola coincidía con el nombre 8.3 de un archivo en el destino, pero es un caso bastante raro. No lo sé con seguridad.

Los archivos 5-10 tienen todos el mismo tipo de corrupción. Un pequeño trozo de datos contiguos en un lugar aleatorio del archivo se cambió por una cadena de datos de aspecto similar. Es demasiado pequeño para detectarlo mediante la reproducción, así que no sé cuál es la copia buena. Ni idea de lo que causó esto.

Los archivos 11 y 12 tienen claramente daños por estar almacenados bajo ZFS. He ejecutado un scrub cada semana y FreeBSD siempre encontraba algo «malo» y lo arreglaba. No me quedaba claro qué eran estos errores o por qué ocurrían, pero me daba malas vibraciones. Me cambié a FreeBSD en primer lugar por los CRC de los archivos de ZFS, pero después de un tiempo llegué a pensar que si NTFS estaba recibiendo archivos corruptos en todas partes el mundo entero lo sabría. Pero la razón principal por la que volví a Windows fue porque no me gustaba la interfaz de FreeBSD.

Me encontré con un quinto tipo de corrupción. La mayoría de las viejas unidades Seagate de 1,5TB en el almacenamiento en frío comenzaron a desarrollar sectores defectuosos. Esto se detectó cuando realicé la comprobación anual de giro, y las unidades fueron reemplazadas antes de que se dañara ningún dato en ellas.

Todavía mantengo un registro de hash MD5 de mis copias de seguridad, pero ya no me preocupa el bitrot. No creo que haya un fenómeno que cambie secretamente bits individuales aquí y allá. Si fuera real, debería haber visto appox 28 bits aislados volteados entre los conjuntos.

Para el consejo práctico, recomiendo mantener una copia de seguridad fuera del sitio de todo, además de una copia de seguridad adicional de las cosas importantes como las fotos de la familia. Asegúrate periódicamente de que tus copias de seguridad pueden ser restauradas. También recomiendo generar listas de archivos para saber qué hay que restaurar cuando hay un fallo en la unidad, y hashes de archivos para poder detectar casos raros de corrupción de archivos. No recomiendo RAID para nada relacionado con las copias de seguridad.

Personalmente creo que la estrategia de copia de seguridad 3-2-1 es un poco pesada para ser utilizada en todos los casos – no voy a mantener 3 copias de alguna vieja ISO de Linux.