Rescatando a Bacula: la migración fallida (por ahora) de un LXC desde Proxmox 4 a Proxmox 8

“A veces, la infraestructura también se cansa… y dice: ‘Estoy cansado, jefe’.”

Estuve lidiando con el envejecimiento de un clúster Proxmox VE 4 (sí, ese que ya tiene más años que algunos desarrolladores juniors). Los cinco nodos funcionaban, pero con cada vez más rarezas: reinicios espontáneos, comandos congelados, y lo peor: el directorio /etc/pve/ se volvía de solo lectura sin aviso.

Durante meses venía trabajando en migrar todas las máquinas virtuales a la nueva generación de servidores, corriendo Proxmox VE 8. La mayoría de las VMs se movieron sin drama… hasta que llegó Bacula.

¿Por qué Bacula era crítico?

Bacula no es cualquier servicio. Es el alma, es el sistema de respaldos en cinta LTO:

  • Maneja dos drives IBM LTO-7 y LTO-8.

  • Escribe backups diarios de sistemas productivos.

  • Usa dispositivos de bloques /dev/st0 y /dev/st1 directamente.

No podía perderlo.

Intento 1: Migrar el LXC como si nada

Primero, copié el disco del contenedor:

(definiendo el nuevo id en el srv destino)

scp root@<...>:/var/lib/vz/images/133/vm-133-disk-1.raw /mnt/pve/gluster_ssd/vm-236-disk-1.raw

Luego, reconstruí el archivo de configuración (236.conf) con soporte para dispositivos de cinta:

lxc.mount.entry: /dev/st0 dev/st0 none bind,optional,create=file
lxc.mount.entry: /dev/st1 dev/st1 none bind,optional,create=file

Todo parecía en orden… hasta que intenté arrancar el contenedor:

Script exited with status 2
Failed to run lxc.hook.pre-start for container “236”

El error venía del hook de Proxmox: no reconocía el storage gluster_ssd como válido para contenedores LXC.
Lección aprendida: no todos los storages soportan rootdir (solo dir, nfs, zfs, etc.).

Solución:

crear un storage de tipo dir apuntando al mismo punto de montaje de GlusterFS:

dir: dir_gluster_ssd
  path /mnt/pve/gluster_ssd
  content rootdir,images

¡Ahora el contenedor arrancaba!

Intenté también recuperar el servicio desde un backup generado en Proxmox 4 (vzdump-lxc-133-<...>.tar.gz), pero arrojó exactamente el mismo error al restaurarlo en PVE8. Incluso el comando pct backup 133 en el nodo antiguo quedaba bloqueado, confirmando que el entorno PVE4 ya no era fiable ni siquiera para operaciones básicas, y mucho menos para servicios de producción.

Pero… no todo era color de cinta LTO

Al entrar al contenedor, el desastre se hizo evidente:

[root@bacula ~]# systemctl status bacula-dir
Failed to get D-Bus connection: No such file or directory

[root@bacula ~]# ip a
eth0: <...> state DOWN

¿Qué pasó?


Proxmox 8 usa cgroups v2 por defecto.
El contenedor, basado en CentOS 7, trae una versión antigua de systemd (< v232), incompatible con cgroups v2.

El resultado:

  • Systemd no se inicia correctamente.

  • La red no levanta.

  • Bacula queda en un limbo técnico.

El propio Proxmox VE 8 lo advierte:

WARN: old systemd (< v232) detected, container won't run in a pure cgroupv2 environment!

¿Y ahora qué?

La migración directa del LXC no es viable en el corto plazo. Pero tengo un plan B:

  1. Mantener el nodo2 aislado del clúster (lo convertí en standalone, y milagrosamente dejó de congelarse).
    → Bacula sigue haciendo backups desde allí.

  2. Migrar Bacula a una VM en Proxmox 8, no a un contenedor.
    → Proxmox 8 sí permite asignar PCI passthrough de tarjetas SCSI a VMs, algo que Proxmox 4 no soporta. Por esa limitación, en su momento se optó por usar un contenedor LXC, ya que desde el kernel de PVE4 sí era posible acceder directamente a las cintas LTO-7 y LTO-8.

Esto implica:

  • Reinstalar Bacula en una VM nueva.

  • Restaurar configuraciones y catálogo desde respaldos.

  • Probar la conexión con los drives físicos.

Pero es el camino más limpio… y seguro.

dashPVE4.png

Moraleja final

No todo lo que se puede copiar, se puede ejecutar.
La evolución del kernel (cgroups v1 → v2), los cambios en la gestión de recursos, y la vida útil de los sistemas operativos dentro de contenedores tienen consecuencias reales.

Proxmox VE 8 es moderno, eficiente… y no perdona la deuda técnica.

A veces, la solución no es forzar una migración, sino replantear la arquitectura.

próximo capítulo: “Bacula en VM: resucitando desde la cinta”.

dashPVE8.png

¡Salud y buen blogging!
— Valerka (Montevideo, Uruguay)
¿Te gustó el post? ¿Tenés dudas, comentarios o querés compartir tu experiencia?
Escribime a: valerkasystem@protonmail.com — ¡Siempre leo los mails y trato de responder cuando puedo!