¿Por qué puede aprobarse una comprobación de integridad del repositorio mientras un archivo sigue sin restaurarse?

Una comprobación del repositorio puede completarse correctamente mientras un archivo no se restaura si la comprobación valida los metadatos o datos muestreados en lugar de esa ruta de recuperación exacta.

La verificación de copias de seguridad no es una operación universal. Algunas comprobaciones confirman la estructura del repositorio, los índices, los manifiestos y los fragmentos referenciados sin leer cada byte almacenado. Otras muestrean datos, omiten archivos que nunca se capturaron o no informan sobre los nombres, permisos, ACL, etiquetas, espacio libre y bloqueos de aplicaciones del sistema de archivos de destino. Trata el archivo que falló como una ruta que va desde la selección de la instantánea, pasando por los objetos almacenados, hasta la creación en el destino.

Identifica exactamente qué verificó la comprobación aprobada

Guarda el comando de comprobación, las opciones, la versión de la herramienta de copia de seguridad, el backend del repositorio, el ID de la instantánea y el registro final. Determina si comprobó la estructura del repositorio, los metadatos del archivo, los fragmentos referenciados, los datos almacenados o una extracción real.

Borg indica que su comprobación estándar del archivo lee los metadatos, pero no los datos de los archivos de forma predeterminada, a menos que se solicite explícitamente la verificación de datos.

Por tanto, un resultado correcto puede demostrar que las referencias son coherentes internamente, pero dejar algunos fragmentos de carga útil sin leer. No consideres que el repositorio se puede restaurar por completo hasta extraer archivos representativos.

Determina si realmente se leyeron los datos almacenados del archivo

Localiza el archivo en la instantánea prevista e identifica los paquetes, fragmentos u objetos necesarios para reconstruirlo. Compara la restauración fallida con el alcance de lectura de datos de la comprobación del repositorio.

Restic documenta las comprobaciones read-data y read-data-subset, lo que demuestra que una comprobación estructural rutinaria y una lectura completa de la carga útil son niveles de verificación diferentes.

Si solo se leyó un subconjunto, el archivo fallido puede depender de un paquete no comprobado. Ejecuta una comprobación de datos específica o completa, según lo que admita la herramienta, antes de intentar reparar el repositorio.

Confirma que el archivo se incluyó en esa instantánea

Enumera la ruta relativa exacta en la instantánea seleccionada. Comprueba los filtros, las exclusiones, las advertencias sobre fuentes ilegibles, las reglas de los enlaces simbólicos, los límites de los puntos de montaje y si la interfaz de restauración seleccionó otra versión.

Kopia advierte que las políticas de ignorados omiten las rutas coincidentes, por lo que la coherencia del repositorio puede verificarse correctamente aunque el archivo deseado nunca se haya capturado.

Una ruta de marcador de posición o una entrada del directorio principal no demuestra que exista la carga útil del archivo. Compara el inventario de la instantánea, el tamaño, el hash y la marca de tiempo con el registro esperado del origen.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Comprueba las restricciones de nombre y ruta del archivo de destino

Restaura el mismo archivo en una ruta local corta y vacía usando un nombre sencillo. Compara los caracteres no válidos, los nombres reservados, las colisiones entre mayúsculas y minúsculas, los espacios finales, la longitud de la ruta y la normalización Unicode.

La guía de Microsoft sobre nombres de archivos documenta las restricciones de nombres y rutas de archivos de Windows, que pueden rechazar una ruta restaurada mientras el repositorio permanece en buen estado.

Si el archivo se restaura en una ruta temporal corta, el contenido almacenado está disponible. Corrige la estructura del destino o la asignación de nombres en lugar de reparar el repositorio.

Verifica la restauración de ACL, atributos extendidos y propiedad

Repite la restauración con la conservación de metadatos desactivada, únicamente en un destino desechable, y compárala con la restauración normal que conserva los metadatos. Registra el primer atributo que falle.

GNU tar documenta por separado la restauración de ACL y atributos extendidos, lo que demuestra por qué los datos del archivo pueden leerse correctamente mientras falla la aplicación de los metadatos.

No aceptes una restauración sin metadatos como solución para producción cuando las aplicaciones dependan de ACL, propiedad, rangos dispersos o atributos extendidos. Úsala únicamente para identificar la capa que falla.

Comprueba las etiquetas de seguridad y la política del destino

Inspecciona las etiquetas de SELinux, el antivirus o la protección de endpoints, los controles contra ransomware, los indicadores de inmutabilidad, los permisos del recurso compartido y los bloqueos de aplicaciones en el destino de restauración.

Red Hat documenta la restauración de los contextos de seguridad predeterminados cuando los archivos llegan con etiquetas ausentes o inadecuadas.

Un archivo que se extrae pero no se puede abrir puede indicar un fallo de la política del destino y no del repositorio. Haz la prueba con el mismo usuario y la misma aplicación que necesiten el archivo restaurado.

Realiza una restauración aislada antes de reparar

Restaura el archivo fallido, los metadatos de su directorio principal y varios archivos cercanos en un conjunto de datos vacío o en un directorio temporal. Guarda los hashes, los registros y el estado del repositorio antes de ejecutar comandos de reparación.

La guía de ZimaSpace sobre la verificación de sumas de comprobación y metadatos explica la diferencia entre la integridad del contenido almacenado y una recuperación utilizable por la aplicación.

El problema se resuelve cuando el archivo seleccionado se restaura desde la instantánea prevista, coincide con el contenido esperado, recibe los metadatos necesarios y se abre mediante la ruta de la aplicación de producción.

Preguntas frecuentes

¿Una comprobación aprobada del repositorio demuestra que todos los archivos se pueden restaurar?

No. Depende de si la comprobación leyó todos los datos almacenados y de si el destino puede recrear cada ruta y sus metadatos.

¿Debo ejecutar una reparación inmediatamente después de que falle una restauración?

No. Primero prueba con otro destino, confirma que el archivo existe en la instantánea y ejecuta una comprobación de datos compatible. La reparación puede eliminar metadatos u objetos dañados.

¿Una restauración de prueba correcta es más sólida que un informe de verificación?

Sí, para la ruta de recuperación probada. Demuestra la selección, el descifrado, la lectura de la carga útil, la creación en el destino y el tratamiento de los metadatos para esa muestra específica.