Fallos de copia/restauración de Proxmox LXC: errores de tar, permisos y trampas del sistema de archivos

Guía rápida de diagnóstico

El objetivo no es admirar el mensaje de error. El objetivo es encontrar el cuello de botella rápido: capacidad de almacenamiento, características del sistema de archivos o mapeo de identidades.
Aquí está el orden que ahorra tiempo.

1) Confirma qué fase falló: creación del backup, compresión o extracción en la restauración

• Si falta el archivo de archivo o es diminuto, es un problema de creación (errores de lectura, permisos, problemas de snapshot).
• Si el archivo existe pero la restauración falla pronto, suele ser xattrs/ACLs/mapeo de propietarios, o el almacenamiento destino no puede representar la metadata.
• Si la restauración falla al final, busca “No space left”, agotamiento de inodos, o timeouts en almacenamiento en red.

2) Identifica el tipo de almacenamiento en ambos extremos (rootfs origen y destino de backup)

Un rootfs LXC sobre ZFS se comporta diferente que un rootfs sobre dir. El destino de backup en NFS se comporta distinto que en ZFS.
“Es solo un archivo” es una mentira reconfortante que tu almacenamiento te castigará.

3) Comprueba si el contenedor es no privilegiado y si la ruta de backup/restauración preserva la propiedad

Los contenedores no privilegiados dependen del mapeo UID/GID. Si restauras sobre un almacenamiento que no puede guardar esos IDs o xattrs, tar se quejará y Proxmox abortará.

4) Reproduce sin compresión y con salida detallada de tar

La compresión oculta el primer error real. Desactívala, reproduce y lee la primera ruta de archivo que falla.

5) Solo entonces persigas “bugs de tar”

Tar suele ser el mensajero. Dispararle no arregla el mensaje.

Cómo Proxmox hace backups de LXC (y dónde encaja tar)

Las copias de LXC de Proxmox suelen estar impulsadas por vzdump. Para contenedores, el “artefacto” por defecto es un archivo tar del sistema de archivos raíz
más metadata (config, puntos de montaje). Dependiendo del modo, Proxmox puede:

• stop mode: detener el contenedor, tar del filesystem de forma consistente, y arrancarlo de nuevo.
• snapshot mode: si el almacenamiento soporta snapshots, tomar uno y tar desde el snapshot mientras el contenedor sigue en ejecución.
• suspend mode: compromiso más antiguo; menos común y menos apreciado.

La clave: incluso si tu rootfs es ZFS, el backup resultante aún suele ser un stream tar a menos que elijas un almacenamiento+formato que soporte snapshots nativos de volumen en el backup.
Ese stream tar transporta metadata: permisos, propietarios, timestamps, nodos de dispositivo, ACLs y atributos extendidos (xattrs).
Si el filesystem origen tiene características que el destino (objetivo de backup) o el destino de extracción no pueden representar, obtendrás fallos que parecen arbitrarios.

Datos interesantes y contexto histórico (porque esto tiene raíces)

1. tar es anterior a Linux por una década. Se construyó para cintas; el comportamiento de “streaming” es la razón por la que aparecen archivos parciales cuando algo interrumpe la tubería.
2. GNU tar añadió soporte para xattr/ACL gradualmente. Las distribuciones antiguas trataban las ACL como un adorno opcional; los contenedores modernos las tratan como identidad.
3. Los contenedores LXC no privilegiados normalizaron el desplazamiento de UID. La convención “root dentro es 100000 fuera” no es universal, pero es común.
4. Proxmox heredó ADN de diseño de las herramientas OpenVZ. El nombre vzdump es un fósil de esa época; aún hace el trabajo.
5. Snapshots de ZFS son baratos; las restauraciones no siempre lo son. Los snapshots son metadata, pero enviar/recibir o extraer un tar es I/O real.
6. NFS tiene múltiples personalidades. v3 vs v4, root_squash y el caching de atributos pueden convertir un “permiso denegado” en teatro de rendimiento.
7. CIFS/SMB no es un filesystem POSIX. Puede emular bits de modo Unix, pero xattrs y nodos de dispositivo son una negociación, no una garantía.
8. Los overlay filesystems cambiaron expectativas. Los contenedores hicieron que la gente espere capas copy-on-write; tar espera inodos y rutas estables.

Una regla operacional que envejece bien: si no puedes restaurar, no tienes un backup. No es poesía, es contabilidad.

Parafraseando una idea de Werner Vogels: “Todo falla, todo el tiempo—diseña y opera asumiendo fallos.” Se aplica brutalmente bien a las copias de seguridad.

Modos de fallo: errores de tar y qué significan realmente

“tar: Cannot open: Permission denied”

Esto rara vez significa “tar carece de permiso”. Usualmente es el proceso de backup de Proxmox ejecutado en el host intentando atravesar una ruta que el host no puede leer
debido a propiedad idmapeada, bind mounts, o un rootfs que no es lo que crees.
Disparadores comunes:

• Bind mount dentro del contenedor desde un directorio con permisos restrictivos en el host.
• Montaje NFS con root_squash donde root del host se convierte en nobody.
• Contenedor no privilegiado donde ciertas rutas tienen propiedad inesperada tras un chown manual o rsync.

“tar: Cannot set xattr” / “Operation not supported”

Esto es un desajuste de características del sistema de archivos. El destino de extracción no soporta el namespace xattr que tar intenta restaurar.
Casos clásicos:

• Restaurar sobre CIFS sin las extensiones Unix adecuadas.
• Restaurar sobre una exportación NFS que elimina xattrs o los mapea de forma extraña.
• Restaurar en un filesystem montado con xattr/acl deshabilitado (sí, aún hay gente que hace eso).

“tar: Cannot change ownership to uid …”

Normalmente una de estas causas:

• Estás restaurando en un rootfs de contenedor no privilegiado sobre un filesystem que no acepta UIDs/GIDs grandes, o estás restaurando sin el contexto de mapeo correcto.
• La extracción se está realizando como un usuario que no puede chown (por ejemplo, backup ejecutándose en un entorno restringido o sobre ciertos filesystems en red).
• El backup se tomó desde un contenedor privilegiado y se restaura en uno no privilegiado (o viceversa) sin ajustar expectativas.

“Unexpected EOF in archive”

Tar es una corriente. Si el proceso que escribe la corriente muere, el lector ve EOF. Causas raíz:

• Se acabó el espacio en el destino de backup a mitad de la transmisión.
• Un fallo de red hacia NFS/CIFS provoca un fallo de escritura y la ruptura de la tubería.
• OOM killer, o timeout en la etapa de compresión (zstd/gzip).

“File changed as we read it”

Esto ocurre cuando haces backup de un filesystem en ejecución sin una barrera de snapshot. Algo de actividad puede ser inocua; otra puede producir un estado de aplicación corrupto.
Si ves esto a menudo, cambia a snapshot mode en almacenamiento compatible, o usa stop mode para consistencia.

Broma #1: Las copias de seguridad son como los paracaídas—si esperas para probarlas durante el salto, te has comprometido a una experiencia de aprendizaje.

Permisos: privilegiado vs no privilegiado, idmaps y por qué root no es root

Los contenedores no son máquinas virtuales. Comparten el kernel del host. Proxmox LXC usa namespaces de usuario de Linux para contenedores no privilegiados.
Eso significa:

• Contenedor privilegiado: root del contenedor mapea a root del host (UID 0).
• Contenedor no privilegiado: root del contenedor mapea a algún UID alto del host (a menudo 100000). La propiedad de archivos en disco refleja UIDs del host, no UIDs del contenedor.

Por qué esto importa para backup/restore:

• Tar almacena UIDs/GIDs numéricos. Si tu backup contiene UIDs desplazados por el host (ej., 100000+), la restauración necesita recrearlos exactamente.
• Algunos filesystems y exports no preservan UIDs grandes bien, o los mapean de forma extraña.
• Los bind mounts pueden introducir mundos de propiedad mixtos: parte del árbol está desplazado, parte no.

Los bind mounts son el saboteador silencioso

Proxmox permite puntos de montaje de contenedor (mp0, mp1, etc.) que hacen bind de rutas del host dentro del contenedor.
Esto es genial hasta que haces backup. Dependiendo de la configuración, esas rutas pueden ser incluidas, excluidas, o comportarse de forma distinta durante tar.
Los permisos del host sobre la ruta origen deciden qué puede leer tar.

Consejo práctico: si usas bind mounts para datos de aplicación, trata esos datos como un dominio de backup separado con su propio método (snapshot del filesystem, volcados de base de datos, etc.).
Intentar “simplemente incluirlo en vzdump” funciona hasta que deja de hacerlo. Y siempre falla en un fin de semana.

Peculiaridades de sistemas de archivos: ZFS, dir, NFS, CIFS, btrfs y compañía

ZFS: los snapshots ayudan, pero las propiedades del dataset todavía pueden perjudicarte

ZFS es el adulto en la sala: snapshots consistentes, checksums, compresión y clones rápidos. Pero no es magia.
Las trampas habituales en restauración son:

• Confusión de mountpoint: restaurar en un dataset que no está montado donde Proxmox espera.
• Permisos del dataset: modo ACL y almacenamiento de xattr definidos de formas que no coinciden con las expectativas del contenedor.
• Refquota/refreservation: la restauración falla a mitad con ENOSPC aunque el pool tenga espacio.

Almacenamiento en directorio (“dir”): simple, legible y sorprendentemente fácil de configurar mal

Un directorio simple como almacenamiento suele estar bien. Tu enemigo aquí no es la complejidad; son las opciones de montaje sutiles:
noacl, nouser_xattr, o almacenar backups en algo como exFAT porque “es solo un disco de backup”.
ExFAT no entiende tus necesidades de metadata Linux. Entiende el arrepentimiento.

NFS: el modelo de permisos es el producto

Si tus backups viven en NFS, necesitas entender:

• root_squash: root del host se convierte en anónimo; tar no puede chown y puede que ni siquiera leer.
• idmapping: NFSv4 mapea por nombre y puede desajustar IDs numéricos, llevando a “propiedad incorrecta tras restaurar”.
• bloqueos y caché de atributos: pueden causar extrañas advertencias de “archivo cambiado” al hacer backup de árboles activos.

CIFS/SMB: bien para documentos de oficina, arriesgado para semánticas de rootfs de contenedor

SMB puede funcionar para archivos de backup (un archivo tar.zst en un share) si los permisos son correctos.
Pero restaurar un rootfs sobre CIFS es mala idea a menos que disfrutes depurar xattrs a las 2 a.m.
Si debes hacerlo: asegura extensiones Unix, xattrs y opciones de montaje adecuadas. Aún así, prueba las restauraciones regularmente.

btrfs: los snapshots están, pero la madurez operacional varía

btrfs puede hacer snapshots y send/receive. En Proxmox, el soporte existe pero es menos común que ZFS en el terreno.
Las trampas tienden a ser:

• Confusión del layout de subvolúmenes llevando a “restauración exitosa pero el contenedor no arranca”.
• Grupos de cuotas provocando ENOSPC inesperado aun con espacio libre aparente.

Broma #2: Tar no te “odia”. Simplemente se niega a mentir sobre la personalidad de tu sistema de archivos.

Tareas prácticas: comandos, qué significa la salida y la decisión que tomas

Estos son los movimientos reales. Cada tarea incluye un comando ejecutable, salida de ejemplo, qué te dice y qué hacer a continuación.
Ejecútalos en el host Proxmox salvo que se indique lo contrario.

Tarea 1: Identificar el rootfs del contenedor y el backend de almacenamiento

cr0x@server:~$ pct config 101 | egrep '^(arch|cores|hostname|ostype|rootfs|unprivileged|mp[0-9]+)'
hostname: app-lxc-01
ostype: debian
arch: amd64
cores: 4
unprivileged: 1
rootfs: local-zfs:subvol-101-disk-0,size=16G
mp0: /srv/data,mp=/var/lib/app-data

Significado: Rootfs es un subvolumen ZFS. El contenedor es no privilegiado. Hay un bind mount (mp0) desde /srv/data.

Decisión: Espera desplazamiento de UID. Trata mp0 por separado; probablemente sea la primera fuente de fallos de permisos.

Tarea 2: Verificar la configuración y tipo del almacenamiento de backups

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        196529976        42108740       144544184   21.43%
local-zfs         zfspool active        2147483648      126903296      2020580352    5.91%
backup-nfs        nfs     active       1953514588      110154852      1843369736    5.64%

Significado: Los backups probablemente van a backup-nfs. NFS implica que root_squash y comportamiento de xattr son sospechosos.

Decisión: Confirma las opciones de export NFS antes de culpar a Proxmox o tar.

Tarea 3: Inspeccionar el log del trabajo fallido para hallar el primer error real

cr0x@server:~$ journalctl -u pvedaemon -S -2h | egrep -i 'vzdump|tar:|error|exit'
Dec 26 11:01:02 server pvedaemon[2218]: vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
Dec 26 11:01:45 server pvedaemon[2218]: tar: ./var/lib/app-data/cache: Cannot open: Permission denied
Dec 26 11:01:45 server pvedaemon[2218]: tar: Exiting with failure status due to previous errors
Dec 26 11:01:45 server pvedaemon[2218]: ERROR: Backup of VM 101 failed - command 'tar ...' failed: exit code 2

Significado: La ruta que falla está dentro del destino del bind mount (/var/lib/app-data), que se mapea a /srv/data en el host.

Decisión: Comprueba permisos en host sobre /srv/data y el squashing NFS si está en un montaje NFS.

Tarea 4: Comprobar si la fuente del bind mount está en NFS/CIFS y con qué opciones

cr0x@server:~$ findmnt -T /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET   SOURCE                  FSTYPE OPTIONS
/srv/data nfs01:/export/appdata  nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.10

Significado: La fuente del bind mount es NFS. Si la exportación tiene root_squash, root del host no podrá leer todo.

Decisión: Valida permisos de exportación. Considera excluir los bind mounts de vzdump y hacer backup vía snapshot nativo del almacenamiento en su lugar.

Tarea 5: Confirmar síntomas de root squashing intentando leer como root

cr0x@server:~$ sudo -n ls -ld /srv/data /srv/data/cache
drwxr-x--- 10 100000 100000 4096 Dec 26 10:40 /srv/data
drwx------  2 100123 100123 4096 Dec 26 10:45 /srv/data/cache

Significado: La propiedad está desplazada (100000+), consistente con datos de contenedor no privilegiado en NFS. Root en host aún puede leer, pero la política de exportación NFS puede anularlo.

Decisión: Si root no puede atravesar, arregla la exportación NFS (no_root_squash para una red de backup/host dedicada) o cambia el enfoque de backup.

Tarea 6: Re-ejecutar el backup sin compresión para sacar rápido el fallo real

cr0x@server:~$ sudo vzdump 101 --storage backup-nfs --mode snapshot --compress none --stdout 0
INFO: starting new backup job: vzdump 101 --storage backup-nfs --mode snapshot --compress none --stdout 0
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating Proxmox Backup archive 'vzdump-lxc-101-2025_12_26-11_07_10.tar'
ERROR: tar: ./var/lib/app-data/cache: Cannot open: Permission denied
ERROR: tar: Exiting with failure status due to previous errors
INFO: removing partial backup file 'backup-nfs:backup/vzdump-lxc-101-2025_12_26-11_07_10.tar'
ERROR: Backup of VM 101 failed - command 'tar' failed: exit code 2

Significado: Mismo fallo, log más limpio. No es la compresión.

Decisión: Deja de probar distintos compresores. Arregla permisos o excluye ese montaje del backup.

Tarea 7: Comprobar puntos de montaje del contenedor y si se incluyen en el backup

cr0x@server:~$ grep -E '^(mp[0-9]+|lxc.mount.entry)' /etc/pve/lxc/101.conf
mp0: /srv/data,mp=/var/lib/app-data

Significado: Ese montaje está definido vía la config de Proxmox. Por defecto, vzdump lo incluirá salvo que se configure lo contrario.

Decisión: Si es datos externos/compartidos, exclúyelo del backup del contenedor y haz backup en la capa de almacenamiento que lo gestiona.

Tarea 8: Verificar capacidad xattr/ACL en el filesystem destino del backup

cr0x@server:~$ findmnt -T /mnt/pve/backup-nfs -o TARGET,FSTYPE,OPTIONS
TARGET            FSTYPE OPTIONS
/mnt/pve/backup-nfs nfs4   rw,relatime,vers=4.1,sec=sys,hard,timeo=600,retrans=2

Significado: NFSv4 puede soportar xattrs, pero la configuración del servidor exportador importa. Además, tu destino de backup solo necesita almacenar el archivo tar; los xattrs importan más en el destino de restauración.

Decisión: Separa “puede escribir el archivo de archive” de “puede restaurar metadata”. Prueba la restauración en el almacenamiento destino previsto.

Tarea 9: Validar un archivo de backup sin restaurarlo (detectar corrupción)

cr0x@server:~$ sudo tar -tf /mnt/pve/backup-nfs/dump/vzdump-lxc-101-2025_12_26-10_00_00.tar.zst | head
./
./etc/
./etc/hostname
./etc/hosts
./var/
./var/lib/
./var/lib/app-data/
./var/lib/app-data/cache/

Significado: Puedes listar el archivo. Si esto falla con “EOF inesperado”, el archivo está corrupto/incompleto.

Decisión: Si está corrupto: investiga interrupción de almacenamiento/red, no permisos del contenedor.

Tarea 10: Confirmar espacio y inodos disponibles en el destino de restauración

cr0x@server:~$ df -h /rpool/data /rpool/data/subvol-101-disk-0
Filesystem      Size  Used Avail Use% Mounted on
rpool           1.8T  1.2T  600G  67% /
rpool/data      600G  410G  190G  69% /rpool/data

cr0x@server:~$ df -i /rpool/data
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
rpool/data            0      0        0     - /rpool/data

Significado: En ZFS, el reporte de inodos es distinto; la falta de números de inodo aquí es normal. Concéntrate en cuotas del dataset y espacio disponible.

Decisión: Si restauras a ext4/xfs, el agotamiento de inodos es real; en ZFS revisa propiedades de cuota en su lugar.

Tarea 11: Comprobar cuotas de dataset ZFS que pueden simular “sin espacio”

cr0x@server:~$ zfs get -o name,property,value -H refquota,quota,used,avail rpool/data/subvol-101-disk-0
rpool/data/subvol-101-disk-0	refquota	16G
rpool/data/subvol-101-disk-0	quota	none
rpool/data/subvol-101-disk-0	used	15.8G
rpool/data/subvol-101-disk-0	avail	200M

Significado: El dataset está limitado por refquota. Aunque el pool tenga terabytes libres, este subvolumen no.

Decisión: Aumenta el tamaño en Proxmox o sube el refquota antes de restaurar, o restaura en un dataset más grande y ajusta el tamaño del disco del contenedor después.

Tarea 12: Inspeccionar el mapeo para contenedores no privilegiados (lado host)

cr0x@server:~$ sudo grep -E '^(root|lxc)' /etc/subuid /etc/subgid
/etc/subuid:root:100000:65536
/etc/subgid:root:100000:65536

Significado: Root del host tiene un rango para mapeo. Si estos rangos faltan o son demasiado pequeños, los contenedores no privilegiados y las restauraciones pueden comportarse de forma extraña.

Decisión: Asegura rangos subuid/subgid consistentes entre nodos del cluster, especialmente si migras/restauras en hosts diferentes.

Tarea 13: Ejecutar una restauración en un ID de contenedor de prueba para probar sin comprometer

cr0x@server:~$ sudo pct restore 999 /mnt/pve/backup-nfs/dump/vzdump-lxc-101-2025_12_26-10_00_00.tar.zst --storage local-zfs
restoring 'vzdump-lxc-101-2025_12_26-10_00_00.tar.zst' to VM 999 ...
extracting archive '/mnt/pve/backup-nfs/dump/vzdump-lxc-101-2025_12_26-10_00_00.tar.zst'
tar: ./var/lib/app-data/cache: Cannot open: Permission denied
tar: Exiting with failure status due to previous errors
ERROR: Restore failed - command 'zstd -q -d -c ... | tar ...' failed: exit code 2

Significado: La restauración falla al extraer el contenido del bind mount. Esto prueba que el problema está en el contenido del archivo y la ruta de permisos, no en el runtime del contenedor.

Decisión: Excluye ese montaje del backup, o arregla acceso para leerlo durante backup/restauración. Si es datos externos, no los metas en el backup del rootfs.

Tarea 14: Confirmar si los puntos de montaje están dentro del archivo (y decidir si deberían estarlo)

cr0x@server:~$ sudo tar -tf /mnt/pve/backup-nfs/dump/vzdump-lxc-101-2025_12_26-10_00_00.tar.zst | egrep '^./var/lib/app-data' | head
./var/lib/app-data/
./var/lib/app-data/cache/
./var/lib/app-data/cache/tmp.db

Significado: Los datos bind-mounted están incluidos en el archivo.

Decisión: Si esos datos residen en almacenamiento compartido (NFS) y tienen su propio ciclo de vida, exclúyelos y haz backup en la capa de almacenamiento. Si no, arregla acceso en el host para leerlos.

Tarea 15: Capturar interferencia de AppArmor/LSM (raro, pero doloroso)

cr0x@server:~$ dmesg -T | egrep -i 'apparmor|denied|audit' | tail
[Thu Dec 26 11:12:22 2025] audit: type=1400 audit(1766747542.123:410): apparmor="DENIED" operation="open" profile="lxc-pct" name="/srv/data/cache/tmp.db" pid=31222 comm="tar" requested_mask="r" denied_mask="r" fsuid=0 ouid=100123

Significado: El kernel denegó la lectura de tar, no fueron los permisos Unix clásicos. Eso es un problema de política.

Decisión: Ajusta el perfil LXC/AppArmor o mueve la ruta de backup/restauración a ubicaciones permitidas por la política. No “desactives AppArmor” como primer recurso.

Tres micro-historias corporativas desde la trinchera

Incidente causado por una suposición errónea: “El bind mount es parte del contenedor, por eso se respalda”

Una empresa SaaS mediana ejecutaba Proxmox con una flota ordenada de LXC. Los equipos de aplicación usaban bind mounts para todo lo stateful:
/srv/postgres dentro del contenedor DB, /srv/uploads dentro del contenedor web, etc.
El equipo de infra asumió que porque Proxmox mostraba el montaje en la config del contenedor, “estaba incluido en el backup”.

El fallo empezó silenciosamente. Los backups “tenían éxito” durante semanas porque las rutas bind-mounted eran legibles la mayoría del tiempo.
Luego se aplicó un cambio en la exportación NFS: se habilitó root squashing ampliamente como parte de un barrido de seguridad.
Aquella noche, vzdump falló en varios contenedores con Permiso denegado. El planificador aún reportó “trabajo ejecutado” y nadie miró.

Dos meses después un contenedor se corrompió durante una actualización. La restauración “funcionó”, el contenedor arrancó y la app se puso en marcha—vacía.
El archivo tenía el rootfs, pero los datos críticos del bind mount nunca se capturaron de forma consistente. Algunas restauraciones fallaron directamente; otras devolvieron un subconjunto obsoleto.
Fue el peor tipo de incidente: recuperación aparentemente exitosa con estado incorrecto.

La solución no fue heroica. Dejaron de tratar los bind mounts como parte del alcance del backup del contenedor.
Los contenedores de base de datos obtuvieron backups lógicos además de snapshots de almacenamiento. Las cargas se replicaron en object storage.
Los backups de vzdump quedaron para rootfs y config, pero ya no pretendían ser la verdad completa.

Optimización que salió mal: “Hagamos backups en SMB porque es más barato y ya está allí”

Otra organización tenía un NAS Windows y un mandato: consolidar backups ahí.
Alguien apuntó el almacenamiento de backups de Proxmox a un share SMB. Funcionó para un puñado de contenedores, así que lo desplegaron ampliamente.
Los costes parecían buenos. La hoja de cálculo sonreía.

La primera grieta apareció durante pruebas de restauración. Contenedores pequeños restauraban bien; los grandes fallaban de forma intermitente con errores de tar:
No se puede establecer xattr, Operación no soportada, y ocasionalmente EOF inesperado.
“Arreglaron” EOF aumentando timeouts y reintentando hasta que quedaba en verde.
Eso no es una solución; es apostar con pasos extra.

El problema profundo: las semánticas de SMB y las opciones de montaje variaban por nodo. Algunos nodos montaban con distinto mapeo uid/gid.
Algunos preservaban xattrs, otros no. El mismo backup se restauraba de forma distinta según dónde lo ejecutaras.
La restauración se convirtió en una lotería con mejor logging.

Finalmente pivotaron a usar SMB solo como repositorio “tonto” para archivos de backup producidos en otro lugar, no como filesystem para restaurar rootfs.
Para restauraciones, extraían sobre almacenamiento local ZFS en el host Proxmox. El problema desapareció. Los costes subieron un poco. El sueño mejoró mucho.

Práctica aburrida pero correcta que salvó el día: drills rutinarios de restauración y un ID de “scratch”

Un entorno regulado ejecutaba Proxmox con ZFS y control de cambios estricto. Su job de backup tenía un requisito “fastidioso”:
cada semana, restaurar dos contenedores aleatorios en un rango de IDs de prueba (900–999) en una red aislada.
A nadie le encantaba gastar tiempo en ello, pero era política.

Una semana, el drill de restauración falló en un contenedor que había sido convertido recientemente a no privilegiado.
Aparecieron errores de tar en torno a propiedad y xattrs. No fue una crisis porque se detectó en el drill, no en un incidente.

La causa fue mundana: un nodo tenía rangos inconsistentes en /etc/subuid tras una reconstrucción.
Los backups estaban bien. Las restauraciones dependían del host. Arreglaron el mapeo, volvieron a ejecutar el drill y siguieron.
La victoria real: lo encontraron antes de que un incidente obligado los forzara a preocuparse.

Esta es la verdad aburrida: el drill de restauración no era glamuroso, pero evitó un fallo de alta tensión y visibilidad después.
No necesitaron heroicidades porque tenían una rutina.

Errores comunes (síntoma → causa raíz → solución)

1) Síntoma: Backup falla con “Permiso denegado” en una ruta bajo /var/lib/...

Causa raíz: Esa ruta es un bind mount desde el host; permisos del host (o NFS root_squash) bloquean tar.

Solución: Asegura que root del host pueda leer la fuente del bind mount; o excluye el montaje del backup del contenedor y haz backup separado.

2) Síntoma: Restauración falla con “Cannot set xattr” o “Operation not supported”

Causa raíz: El filesystem/export destino no soporta los xattrs/ACLs del archivo.

Solución: Restaura sobre almacenamiento POSIX nativo (ZFS, ext4, xfs). Evita restaurar rootfs sobre CIFS; valida soporte xattr en NFS export.

3) Síntoma: Restauración falla con “Cannot change ownership” o muchos UIDs numéricos en logs

Causa raíz: Desplazamiento de UID en contenedor no privilegiado; el entorno de restauración no puede representar o aplicar esas propiedades.

Solución: Mantén subuid/subgid consistentes entre nodos. Restaura sobre almacenamiento que soporte chown y UIDs grandes. No mezcles privilegiado/no privilegiado sin plan.

4) Síntoma: “EOF inesperado” al listar o restaurar un archivo

Causa raíz: Archivo incompleto (escritura interrumpida, sin espacio, caída de red, proceso matado).

Solución: Revisa capacidad de almacenamiento, estabilidad NFS y logs del sistema por OOM kills. Prefiere staging en almacenamiento local rápido si la red es inestable.

5) Síntoma: Backup tiene éxito pero la restauración produce permisos incorrectos dentro del contenedor

Causa raíz: Restaurar sobre filesystem que remapea propiedad (algunas configuraciones NFSv4) o pierde ACLs/xattrs.

Solución: Restaura sobre ZFS/ext4/xfs local y luego migra. O ajusta idmapping NFS para que sea consistente y prueba.

6) Síntoma: Restauración falla con ENOSPC aunque el pool tiene espacio

Causa raíz: Refquota/quota de ZFS o qgroups de btrfs limitan el dataset/subvolumen.

Solución: Aumenta tamaño/cuotas del dataset antes de restaurar. No confíes en “pool free” como respuesta final.

7) Síntoma: Advertencias “File changed as we read it”, a veces seguidas de estado de app roto

Causa raíz: Backup tomado sin una barrera de snapshot adecuada para una carga de trabajo con mucha actividad.

Solución: Usa snapshot mode en almacenamiento con capacidad de snapshots, o stop mode para consistencia. Para bases de datos, haz backups lógicos.

8) Síntoma: Restauración funciona en un nodo pero falla en otro

Causa raíz: Configuración de host inconsistente: subuid/subgid, opciones de montaje, versiones de plugins de almacenamiento o montajes NFS.

Solución: Estandariza configuraciones de nodos, trátalos como ganado, y ejecuta drills de restauración en múltiples nodos.

Listas de comprobación / plan paso a paso

Paso a paso: desde el log fallido hasta la causa raíz en menos de 30 minutos

1. Obtén la primera ruta que falla desde journalctl o el log de vzdump. Ignora la última línea de error; suele ser genérica.
2. Mapea la ruta a la config del contenedor: ¿está bajo un bind mount (mpX)? Si sí, trátalo como almacenamiento externo.
3. Confirma tipos de almacenamiento (storage del rootfs, storage de backup, storage target de restauración) con pvesm status y findmnt.
4. Revisa permisos en el host para el archivo/dir exacto que falla. Si es NFS/CIFS, revisa la política de exportación/share, no solo los bits de modo.
5. Re-ejecuta sin compresión para obtener errores deterministas y evitar ruido de CPU.
6. Valida la integridad del archivo vía tar -t antes de intentar restaurar repetidamente.
7. Para contenedores no privilegiados, verifica consistencia de subuid/subgid y evita restaurar sobre filesystems no POSIX.
8. Arregla la causa, luego ejecuta una restauración de prueba en un CTID nuevo antes de tocar el ID de producción.

Checklist operacional: hacer las restauraciones LXC aburridas

• Mantén rootfs de contenedores en ZFS o en un filesystem POSIX local sensato.
• Usa backups por snapshot cuando esté soportado; usa stop backups para servicios que requieren corrección.
• No confíes en bind mounts para “inclusión automática” en backups. Decide explícitamente.
• Estandariza /etc/subuid y /etc/subgid en todos los nodos del cluster.
• Almacena archivos de backup donde quieras, pero restaura sobre almacenamiento que preserve metadata.
• Ejecuta restauraciones de prueba rutinarias. Rota el nodo que las realiza.
• Trata las fallas de backup como alertas, no como “alguien se dará cuenta”.

Guía de decisión: elige el alcance de backup correcto

• Rootfs del contenedor + config: vzdump está bien. Restauraciones son rápidas y predecibles en ZFS/almacenamiento local.
• Datos stateful bind-mounted: haz backup usando el sistema de almacenamiento que los posee (snapshots ZFS, snapshots del servidor NFS, volcados nativos de base de datos).
• Bases de datos: prioriza backups lógicos y replicación sobre consistencia de tar a nivel de filesystem.

FAQ

1) ¿Por qué Proxmox usa tar para backups de LXC en vez de solo snapshots?

Portabilidad. Un archivo tar se puede almacenar en cualquier lugar y restaurar en distintos backends. Los snapshots son específicos del almacenamiento; tar es el mínimo común denominador.

2) ¿Es “exit code 2” de tar siempre una falla fatal de backup?

En este contexto, trátalo como fatal. Tar usa el código 2 para “errores fatales”. Proxmox normalmente marcará el backup como fallido y puede borrar la salida parcial.

3) ¿Puedo ignorar advertencias “file changed as we read it”?

Para un servidor con mucha actividad, a veces. Para una base de datos o cualquier cosa transaccional, no. Si quieres restauraciones consistentes, usa snapshot mode o stop mode, además de backups consistentes a nivel de aplicación.

4) ¿Por qué los contenedores no privilegiados complican la restauración?

Porque la propiedad en disco está desplazada (UIDs/GIDs altos). El proceso de restauración debe recrear fielmente esos IDs numéricos y la metadata. Algunos backends de almacenamiento no lo harán.

5) Mis backups están en NFS. ¿Es eso malo?

No inherentemente. Almacenar archivos de backup en NFS es común. El riesgo aumenta si tus datos de contenedor están en NFS vía bind mounts, o si intentas restaurar rootfs sobre NFS.

6) ¿Por qué restaurar sobre CIFS falla a veces con errores xattr/ACL?

CIFS no es nativo POSIX. Si soporta xattrs, ACLs y nodos de dispositivo depende de las funciones del servidor y opciones de montaje. Los contenedores esperan semánticas Linux.

7) ¿Cuál es el flujo de restauración más seguro?

Restaurar a un nuevo CTID en ZFS local (o ext4/xfs), validar arranque y comprobaciones de la aplicación, luego cambiar el tráfico y dar de baja el contenedor roto.
No restaures en sitio a menos que quieras alargar la indisponibilidad.

8) ¿Por qué la restauración falla con “no space left” cuando el pool ZFS tiene mucho espacio?

Porque el dataset puede estar limitado por refquota u otra propiedad similar. La restauración escribe en el dataset, no en todo el pool.
Revisa avail del dataset, no el espacio libre del pool.

9) ¿Cómo debo manejar bind mounts en backups de la forma “correcta”?

Decide si los datos bind-mounted forman parte del objetivo de recuperación del contenedor. Si sí, haz backup explícito usando un método adecuado al almacenamiento.
Si no, exclúyelos del alcance del backup del contenedor y documenta la dependencia.

10) ¿Debería cambiar todo a contenedores privilegiados para evitar problemas de mapeo UID?

No. Eso cambia conveniencia operativa por un mayor radio de impacto. Arregla la consistencia de mapeos y la compatibilidad de almacenamiento en su lugar. Los contenedores privilegiados no son una solución gratuita.

Conclusión: próximos pasos que realmente reducen el riesgo

Cuando la copia/restauración Proxmox LXC falla con errores de tar, el movimiento ganador es dejar de leer la salida de tar como si fuera un acertijo.
Normalmente te está diciendo una de tres verdades: el host no puede leer una ruta, el destino no puede representar metadata, o el almacenamiento se quedó sin algo a mitad de la transmisión.

Haz esto a continuación:

1. Ejecuta hoy una restauración de prueba para un contenedor representativo. Si no puedes restaurar a demanda, trátalo como incidente.
2. Inventaría los bind mounts en tus contenedores y decide si cada uno está en el alcance de backups a nivel de contenedor.
3. Estandariza subuid/subgid y opciones de montaje de almacenamiento entre nodos Proxmox. La deriva genera “funciona en mi nodo”.
4. Prefiere restaurar sobre ZFS/almacenamiento POSIX local. Usa shares de red para almacenar archivos de backup, no como filesystem que debe contener un rootfs de contenedor.
5. Convierte los drills de restauración en rutina. La aburrición es el objetivo.