¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

Una restauración de un volumen de Docker puede recrear cada byte de los archivos y, aun así, perder los atributos extendidos cuando el formato de copia de seguridad, las opciones, los privilegios o el destino no pueden conservarlos.

Los atributos extendidos son pares de metadatos de nombre y valor almacenados fuera del contenido habitual de los archivos, la propiedad, los bits de permisos y las marcas de tiempo. Pueden contener datos de ACL, etiquetas de SELinux, capacidades de Linux, indicadores de aplicaciones o metadatos de Samba. Una copia de seguridad sencilla de un volumen basada en tar puede restaurar un directorio que parece completo, mientras las aplicaciones se comportan de forma diferente porque el archivo no registró los xattrs o el proceso de restauración no pudo escribir en un espacio de nombres protegido.

Inventaría los atributos de origen antes de repetir la restauración

Selecciona archivos representativos y registra sus hashes, propietario, permisos, ACL y todos los nombres y valores de los atributos extendidos. Incluye los archivos que fallen en la aplicación después de la restauración.

El modelo de xattr de Linux separa los espacios de nombres user, system, security y trusted, cada uno con distintos requisitos de acceso y privilegios.

Si el origen no tiene xattrs, la restauración no los perdió. Si desaparece solo un espacio de nombres, centra la investigación en los privilegios, la política de seguridad o la compatibilidad del destino, no en la capa de contenido de archivos del archivo.

Comprueba qué archivó realmente el comando de copia de seguridad de Docker

Guarda la imagen exacta, el comando, el directorio de trabajo, el formato del archivo, el usuario, el origen montado y el destino de copia de seguridad montado que utilizó el contenedor de copia de seguridad.

El ejemplo de copia de seguridad de volúmenes de Docker utiliza tar dentro de un contenedor auxiliar, pero la conservación de metadatos sigue dependiendo de la implementación de tar y de las opciones seleccionadas.

Un archivo de archivo creado correctamente demuestra que se leyeron las entradas de directorio y la carga útil, pero no que se incluyera cada espacio de nombres xattr. Inspecciona el archivo con la misma herramienta que utilizaste para crearlo.

Activa los atributos extendidos al crear y extraer el archivo

Compara las opciones de tar utilizadas durante la copia de seguridad y la restauración. Confirma que los xattrs se activaron en ambas direcciones y que los patrones de inclusión o exclusión no eliminaron los espacios de nombres necesarios.

GNU tar indica que --xattrs almacena y restaura los atributos extendidos.

Agregar la opción solo durante la extracción no puede recuperar atributos que nunca se almacenaron. Crea un archivo pequeño nuevo a partir de un archivo de origen con un xattr de prueba conocido e inspecciónalo antes de cambiar las copias de seguridad de producción.

Utiliza las opciones correctas de metadatos de Rsync para copias de seguridad basadas en archivos

Si la copia de seguridad del volumen utiliza Rsync, inspecciona las opciones de archivo, ACL, xattr, ID numéricos, fake-super y privilegios tanto en el emisor como en el receptor.

El manual oficial de Rsync documenta -X para conservar los atributos extendidos y describe el almacenamiento fake-super cuando los metadatos con privilegios no se pueden aplicar directamente.

La opción de archivo habitual -a no incluye automáticamente todos los requisitos de ACL y xattr. Prueba el comando exacto en los sistemas de archivos reales de origen y destino.

Verifica la compatibilidad del sistema de archivos y del montaje de destino

Crea un archivo desechable directamente en el volumen restaurado e intenta establecer, enumerar y eliminar un xattr de usuario. Repite la prueba desde el host y desde el contenedor de copia de seguridad.

Utiliza una herramienta de listado de atributos dentro del host y del contenedor de restauración para demostrar si el destino acepta y devuelve xattrs, independientemente del archivo de copia de seguridad.

Si la creación directa de xattrs falla, inspecciona el tipo de sistema de archivos, las opciones de montaje, el protocolo de red, el controlador del volumen y la compatibilidad del dispositivo de almacenamiento. Ninguna opción del archivo puede restaurar metadatos que el destino no pueda representar.

Comprueba los privilegios para los espacios de nombres security y trusted

Registra el usuario del contenedor de restauración, las capacidades, el espacio de nombres de usuario, el modo rootless, la política de SELinux y si la ruta del volumen está montada mediante bind desde el host.

Red Hat documenta que las etiquetas de SELinux pueden requerir una restauración conforme a la política después de copiar o recrear archivos.

No concedas permanentemente privilegios amplios del host a un contenedor de copia de seguridad. Utiliza un entorno de restauración controlado o restaura primero los datos normales y vuelve a aplicar las etiquetas gestionadas por la política con herramientas compatibles.

Distingue entre ACL, capacidades y xattrs específicos de las aplicaciones

Compara por separado las entradas de ACL POSIX, las capacidades de archivos de Linux, las etiquetas de SELinux, los xattrs de usuario y los metadatos de Samba o macOS. Pueden fallar por motivos diferentes.

El módulo xattr_tdb de Samba puede almacenar los xattrs por separado del sistema de archivos subyacente.

Por lo tanto, un archivo de copia de seguridad del volumen a nivel de archivo puede conservar el árbol de archivos visible, pero no una base de datos de metadatos de Samba independiente. Incluye todos los almacenes de metadatos dependientes o recréalos mediante el proceso compatible de la aplicación.

Restaura un archivo de prueba y valida la aplicación

Crea un archivo de origen conocido con un hash de contenido, una ACL, un xattr de usuario y cualquier metadato de aplicación necesario. Haz una copia de seguridad y restáuralo en un volumen desechable.

El artículo de ZimaSpace sobre los cambios de permisos y metadatos al migrar a un NAS aborda un comportamiento de migración más amplio; este artículo se centra en la copia de seguridad y restauración de volúmenes de Docker.

El problema se resuelve cuando los hashes de contenido, los nombres y valores de xattr necesarios, las ACL, las etiquetas de seguridad y el comportamiento de la aplicación coinciden después de una segunda copia de seguridad y restauración controladas.

Preguntas frecuentes

¿Los atributos extendidos son lo mismo que las ACL?

No. En algunos sistemas de archivos, las ACL pueden implementarse mediante xattrs del sistema, pero los xattrs también almacenan etiquetas de seguridad, capacidades, metadatos de usuario y valores específicos de las aplicaciones.

¿tar conserva los atributos extendidos de forma predeterminada?

No lo des por hecho. GNU tar ofrece opciones explícitas para xattrs, y el archivo debe almacenar los atributos durante su creación para que la extracción pueda restaurarlos.

¿Una restauración puede perder los xattrs aunque se ejecute como root?

Sí. Es posible que el archivo no los contenga, que el destino no los admita, que una política de seguridad los rechace o que los metadatos se encuentren en una base de datos independiente de la aplicación.

Soporte y Consejos

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.