Cuando pensamos en la pérdida de datos, la mayoría de la gente seguramente recuerde alguna infección de algún virus que ha borrado o cifrado sus datos o de alguna vez que su disco duro ha empezado a fallar. Pero la realidad va más allá.
Esos son los dos casos típicos en los que se puede pensar. Pero el hardware encargado de almacenar nuestra información tiene una tasa de fallos en su funcionamiento normal que nos puede hacer perder nuestros preciados datos.
La inmensa mayoría de sistemas de archivos no realizan una comprobación de la información almacenada ni cuando se escribe ni una vez que se ha escrito. En Linux hay algunas excepciones y el sistema de archivos ZFS dispone de un mecanismo de comprobación que sí realiza estos chequeos. Pero ¿por qué NTFS o ext4 no comprueban si lo grabado es correcto? La respuesta es que la controladora y los protocolos encargados de mover nuestros datos (principalmente SATA) ya disponen de sistemas de corrección de errores. El problema es que estos sistemas son falibles. Y de hecho fallan.
Cuando hablamos de hechos estocásticos, por una parte podemos predecir la fuente del error y, por lo tanto, podemos encontrar una solución antes de que se produzca el desastre (SMART en un buen mecanismo predictivo). Lamentablemente, detrás de estos sucesos también existen variables absolutamente imposibles de predecir que hacen que las probabilidades de que se produzca corrupción de datos no sean nulas.
Aquí la cuestión es que la mayoría de usuarios ni siquiera se da cuenta de estos errores, ya que se producen de una forma completamente transparente y en una cantidad de bytes muy reducida. Además, en discos de varios terabytes es habitual que tengamos una gran cantidad de datos a los que accedemos muy de vez en cuando. Podemos haber grabado un puñado de gigabytes con algunos bytes que no debería estar ahí y nada nos avisaría de este suceso.
John Goerzen ha publicado en su blog una entrada que explica su experiencia. Se dio cuenta del problema gracias a los mensajes de advertencia que daba ZFS. Al principio, como cualquiera podría pensar, sospechó de la RAM pero estaba en perfectas condiciones. Más tarde cambio el disco duro pero seguía fallando. No olvidó probar otras controladoras SATA con el mismo resultado. Finalmente decidió invertir en un nuevo cable SATA y los problemas desaparecieron.
La concepción general es que un cable SATA defectuoso no funciona. De echo es lógico pensar que si la controladora no encuentra una buena comunicación el disco, decida no funcionar. Pero hay veces que un cable con un pequeño defecto sí funciona. En principio esto no debería ser un problema ya que el protocolo SATA usa un mecanismo llamado CRC32 que verifica la integridad de todas las tramas intercambiadas con el disco. Pero no es un sistema perfecto y aunque el hardware se considere apto para funcionar, se podrían producir fallos indetectables.
La conclusión que se puede sacar es que un equipo que aparentemente está en perfectas condiciones, puede provocar corrupción de datos sin que el usuario se de cuenta ya que después de la comprobación CRC32 de SATA, en realidad no hay nada que esté comprobando que nuestros datos son correctos.