¿Por qué una instantánea de un NAS doméstico puede preservar datos que ya están corruptos?

Una instantánea de un NAS doméstico puede preservar datos corruptos porque su función es retener un estado del sistema de archivos, no decidir si cada archivo en ese estado está saludable. Si una base de datos, documento, foto o archivo multimedia ya está dañado cuando se crea la instantánea, restaurar esa instantánea puede reproducir la misma versión dañada.

El momento de la corrupción importa. Una instantánea puede proteger una versión anterior de una sobrescritura posterior, pero no puede crear una versión limpia que nunca fue capturada. La compartición de bloques copy-on-write también crea un segundo caso: el daño físico a un bloque puede afectar más de una vista del sistema de archivos que aún referencia ese bloque.

Una instantánea preserva un estado del sistema de archivos, no una copia conocida como buena

Una instantánea del sistema de archivos registra un estado de almacenamiento en un momento particular. En OpenZFS, por ejemplo, una instantánea es una versión de solo lectura de un sistema de archivos o volumen, y inicialmente comparte datos con el conjunto de datos activo en lugar de duplicar cada archivo. La documentación de instantáneas de OpenZFS describe cómo la instantánea retiene datos que de otro modo permanecerían compartidos hasta que el conjunto de datos activo cambie.

Esa operación no establece si el contenido almacenado es semánticamente correcto. Un sistema de archivos puede preservar un archivo estructuralmente legible incluso cuando una aplicación ha escrito registros inválidos, una herramienta de sincronización ha copiado la versión incorrecta o un ransomware ha reemplazado los bytes originales con contenido cifrado. Por lo tanto, el éxito de la instantánea significa que se retuvo un estado; no certifica que el estado fuera bueno.

La corrupción presente en el momento de la instantánea se convierte en parte del punto de recuperación

Considere una instantánea programada creada a medianoche. Si una aplicación corrompe una base de datos a las 10:00 p.m., la instantánea de medianoche registra el estado del sistema de archivos posterior a la corrupción. Volver a esa instantánea devuelve la base de datos a medianoche, pero medianoche ya es demasiado tarde para proporcionar una copia saludable.

La misma secuencia puede ocurrir después de una sincronización defectuosa, una importación incompleta, un guardado accidental o un cifrado no autorizado. La instantánea no “incorpora” la corrupción como una propiedad especial; simplemente conserva la versión que existía en el momento de la captura. Una instantánea más antigua puede contener una versión utilizable, pero cada instantánea creada después del daño puede contener el mismo error lógico.

El momento de la corrupción determina si una instantánea puede ayudar

Una instantánea es más útil cuando el cambio lógico no deseado ocurre después del punto de recuperación. Si la instantánea del lunes contiene un archivo saludable y el archivo en vivo se sobrescribe el martes, la vista del lunes aún puede mostrar los datos anteriores. Si el archivo ya estaba dañado el lunes, ese mismo punto de recuperación no puede resolver el problema.

El daño en el almacenamiento subyacente crea un camino diferente. Una instantánea puede haber estado sana cuando se creó, pero luego volverse ilegible si un bloque físico que aún referencia está dañado y el sistema de archivos no puede reconstruir una copia verificada. Por eso, el momento de la corrupción debe considerarse junto con el compartir bloques y la redundancia del almacenamiento.

El Compartir Bloques por Copia en Escritura Puede Exponer Un Bloque Dañado a Través de Instantáneas

Las instantáneas de copia en escritura son eficientes en espacio porque los datos sin cambios se comparten. La documentación del modelo de almacenamiento Btrfs explica que una instantánea y su subvolumen fuente comparten sus datos comunes no modificados. Por lo tanto, una instantánea es una vista histórica del sistema de archivos, no automáticamente una segunda copia física en medios separados.

Cuando el archivo en vivo se modifica normalmente, la copia en escritura asigna nuevo almacenamiento para el cambio mientras la instantánea continúa haciendo referencia a los bloques anteriores. Esta separación es lo que hace posible la reversión. Sin embargo, si un bloque sin cambios sigue siendo compartido y ese bloque almacenado luego se vuelve ilegible o devuelve datos incorrectos, todas las vistas que dependen de él pueden encontrar la misma falla.

Las sumas de verificación y el almacenamiento redundante pueden cambiar el resultado al detectar la discrepancia y proporcionar otra copia, pero la instantánea en sí no crea esa protección. La copia en escritura proporciona separación de versiones; no crea un dominio independiente de fallos de hardware.

Las sumas de verificación y los escaneos prueban la integridad; las instantáneas no.

Las instantáneas, sumas de verificación y escaneos pertenecen a diferentes partes de la pila de protección. Una instantánea preserva el historial, una suma de verificación ayuda a determinar si los bytes almacenados cambiaron inesperadamente, y un escaneo lee proactivamente los datos almacenados para buscar errores. Tratar estas funciones como intercambiables conduce a una falsa confianza sobre lo que un punto de recuperación puede demostrar.

Las sumas de verificación pueden detectar cambios inesperados en los bloques

La documentación de suma de verificación de Btrfs indica que las sumas de verificación se calculan antes de las escrituras y se verifican después de que los bloques se leen del almacenamiento. Una discrepancia puede revelar que el bloque recuperado no es el mismo que el bloque que el sistema de archivos esperaba almacenar.

Una suma de verificación coincidente no prueba que un documento, base de datos o archivo multimedia sea lógicamente correcto. Si una aplicación escribe datos erróneos a través de la ruta normal de escritura, el sistema de archivos puede calcular una suma de verificación válida para esos bytes erróneos. El bloque está intacto desde la perspectiva del sistema de archivos aunque el contenido a nivel de aplicación sea inutilizable.

La redundancia determina si un scrub puede reparar el daño

Un scrub puede detectar errores de suma de verificación, errores de lectura y ciertos problemas de metadatos, pero la detección no es lo mismo que la reparación. La documentación de Btrfs scrub explica que la reparación automática en almacenamiento replicado usa datos verificados y buenos de otra réplica. Sin una copia alternativa válida, el sistema de archivos puede identificar el bloque dañado sin poder reconstruirlo.

Un estudio USENIX sobre la integridad de datos en ZFS separa de manera similar la detección basada en sumas de verificación de la recuperación mediante redundancia. La lección práctica es más limitada que “los scrubs arreglan la corrupción”: un scrub solo puede reparar las fallas para las cuales el sistema de almacenamiento puede localizar o reconstruir datos de reemplazo confiables.

La retención de instantáneas solo ayuda si aún existe un estado saludable

La corrupción no siempre se detecta de inmediato. Una foto, archivo o proyecto que se abre raramente puede permanecer dañado durante semanas antes de que alguien intente usarlo. Si la rotación de instantáneas ya ha eliminado todas las versiones anteriores al daño, una colección profunda de instantáneas recientes aún puede no contener un punto de recuperación saludable.

Por lo tanto, la retención debe reflejar la ventana probable de detección, no solo la frecuencia con la que se crean las instantáneas. Las instantáneas horarias proporcionan un historial reciente detallado, mientras que los puntos diarios, semanales o mensuales de mayor duración extienden el período en el que se puede escapar un error no detectado. No existe un calendario universal: el intervalo útil depende de la tasa de cambio, la capacidad disponible y la rapidez con la que normalmente se revisan los archivos importantes.

Verifique una instantánea antes de reemplazar datos NAS en vivo

Elegir una instantánea por fecha es solo el primer paso. Antes de revertir un conjunto de datos completo o reemplazar el archivo en vivo, restaure una versión candidata en una ubicación separada cuando la plataforma NAS doméstica lo permita. Esto evita que un intento de recuperación no verificado sobrescriba datos más nuevos que aún pueden ser útiles.

1. Estime cuándo apareció la corrupción por primera vez.
2. Seleccione una instantánea anterior a ese momento.
3. Restaure el candidato en una carpeta o clon alternativo.
4. Abra, valide o compare el contenido recuperado antes de reemplazar los datos en vivo.

La validación debe coincidir con el tipo de datos. Una suma de verificación conocida puede verificar un archivo sin cambios, mientras que una base de datos puede requerir su propia comprobación de consistencia y una foto o video puede necesitar ser decodificado. Para la relación más amplia entre puntos de recuperación, copias independientes y protección fuera del dispositivo, consulte esta estrategia de respaldo para NAS domésticos.

Preguntas frecuentes

¿Puede una instantánea tomada antes de la corrupción volverse ilegible?

Sí. Una instantánea protege un estado lógico anterior de cambios posteriores en los archivos, pero aún puede compartir el mismo grupo de almacenamiento y bloques físicos. Si uno de esos bloques está dañado y no hay una copia redundante verificada disponible, la instantánea anterior puede volverse ilegible aunque sea anterior a la corrupción lógica que se investiga.

¿Significa una instantánea exitosa que cada archivo dentro de ella está saludable?

No. Una instantánea exitosa indica que el sistema de archivos creó el punto de recuperación. No significa que cada archivo haya sido abierto, decodificado, verificado contra una versión confiable o validado por la aplicación que lo creó.

¿Puede un escaneo de datos reparar la corrupción escrita por una aplicación?

Generalmente no cuando la aplicación escribió el contenido incorrecto normalmente. En ese caso, el sistema de archivos puede almacenar los bytes dañados con una suma de verificación válida, sin dejar ninguna discrepancia a nivel de bloque para que el escaneo la detecte. La recuperación requiere una versión saludable anterior, un proceso de reparación consciente de la aplicación o una copia independiente.

¿Reemplazar un archivo en vivo corrupto repara instantáneas antiguas?

No. Reemplazar el archivo en vivo escribe o hace referencia a datos saludables para el conjunto de datos activo, pero las instantáneas antiguas continúan representando sus estados históricos. Una instantánea que retuvo la versión corrupta normalmente permanece corrupta hasta que expira o se elimina.