Una máquina virtual Docker por aplicación frente a un LXC por aplicación: ¿cuál ofrece un mejor control de las copias de seguridad y del alcance de los daños?
Elige una sola VM de Docker cuando las aplicaciones compartan un entorno operativo común, un proxy inverso, una pila de monitorización y un calendario de copias de seguridad, y cuando sea aceptable restaurar toda la plataforma de aplicaciones en conjunto. Elige un LXC por aplicación cuando los servicios tengan distintos requisitos de riesgo, actualización, almacenamiento o recuperación, y un paquete, montaje o aplicación defectuosos no deban interrumpir el resto de la pila. El mejor diseño es la unidad de recuperación más pequeña que puedas documentar sin multiplicar dependencias ocultas.
Define la unidad de recuperación antes de comparar contenedores
La primera decisión no es si Docker o LXC utiliza menos recursos. Es qué elementos deben restaurarse juntos después de una actualización fallida, una base de datos dañada, un montaje defectuoso o el reemplazo del host. Una sola VM de Docker crea una unidad de recuperación grande que incluye el sistema operativo y el motor de contenedores. Un LXC por aplicación crea varias unidades más pequeñas, cada una con su propio sistema de archivos, identidad de red, límites y objeto de copia de seguridad.
La guía de ZimaSpace sobre las capas de almacenamiento de bare metal, Docker y Proxmox explica por qué cada capa añadida cambia dónde se almacenan los datos persistentes. Esta comparación comienza después de haber elegido Proxmox y plantea qué tamaño debe tener el límite de recuperación de cada aplicación.
Si las aplicaciones no pueden iniciarse de forma independiente porque comparten una base de datos, una red de Compose, un proveedor de identidad o una configuración de proxy inverso, crear LXCs separados puede producir varios archivos de copia de seguridad sin ofrecer un aislamiento real. Mapea las dependencias antes de contar los contenedores.
| Criterio de decisión | Una VM de Docker | Un LXC por aplicación |
|---|---|---|
| Objeto de copia de seguridad | Una copia de seguridad de VM más grande, además de protección de datos específica de la aplicación | Una copia de seguridad de Proxmox más pequeña por cada contenedor de aplicación |
| Alcance de la restauración | Restaura toda la plataforma Docker en conjunto | Restaura un servicio sin reemplazar invitados no relacionados |
| Herramientas compartidas | Un demonio de Docker, un proxy, un agente de monitorización y un ciclo de parches | Paquetes base, agentes, usuarios y reglas de red repetidos |
| Alcance del impacto de las actualizaciones | Los cambios en el kernel, Docker, el firewall o el sistema de archivos pueden afectar a todas las aplicaciones | La mayoría de los cambios en paquetes y aplicaciones permanecen dentro de un solo LXC |
| Sobrecarga de recursos | Un sistema operativo invitado, pero todas las aplicaciones compiten dentro de él | Poca sobrecarga por contenedor, con configuraciones base de servicio repetidas |
| Comunicación entre aplicaciones | Redes de Docker sencillas y proyectos compose compartidos | Requiere redes enrutadas, DNS, credenciales y políticas de firewall |
| Más adecuado | Plataforma de aplicaciones estrechamente relacionada, con un único operador y calendario de recuperación | Servicios independientes con distintos requisitos de riesgo y ciclo de vida |
Una sola VM de Docker simplifica las copias de seguridad de la plataforma
Una sola VM puede contener el huésped Linux, Docker Engine, los archivos compose, los secretos, la configuración del proxy, las imágenes de contenedor y los volúmenes persistentes. Proxmox puede respaldar la VM como un único objeto, lo que simplifica la sustitución del host y la reversión general cuando toda la plataforma debe volver al mismo momento.
Una guía reciente sobre la restauración de VM y contenedores LXC en Proxmox señala que las restauraciones de LXC suelen ser más ligeras porque archivan el sistema de archivos de un contenedor en lugar de un disco virtual completo. La ventaja inversa de una VM es la integridad: una sola restauración puede devolver conjuntamente el sistema operativo huésped y el entorno de Docker.
Esta simplicidad es mayor cuando las aplicaciones forman intencionadamente una sola plataforma. Un conjunto multimedia puede compartir un proxy inverso, autenticación, herramientas de descarga, monitorización y montajes de almacenamiento. Restaurar solo una pieza puede generar incompatibilidades de versiones o credenciales, por lo que una copia de seguridad coordinada de una VM puede ajustarse mejor al límite real de dependencias.
Los LXC separados ofrecen unidades de fallo y restauración más pequeñas
Un LXC por aplicación permite que un paquete defectuoso, un sistema de archivos raíz completamente lleno, una configuración dañada o una actualización fallida queden confinados a un solo huésped. El operador puede restaurar ese contenedor sin revertir servicios no relacionados que se modificaron correctamente después del mismo punto de respaldo.
El argumento práctico a favor de unos radios de impacto más pequeños para los servicios en Proxmox no es que todas las aplicaciones deban ejecutarse automáticamente en un contenedor. Es que el aislamiento aporta valor cuando los servicios tienen distintos requisitos de confianza, mantenimiento o disponibilidad.
La ventaja desaparece cuando todos los LXC montan el mismo directorio de aplicaciones con permisos de escritura, dependen de una base de datos sin protección o requieren el mismo proxy y servicio de identidad. Un sistema de archivos raíz independiente no puede contener un fallo que se propaga a través de credenciales, almacenamiento o automatización destructiva compartidos.
La granularidad de las copias de seguridad puede generar más trabajo de restauración
Las copias de seguridad más pequeñas permiten al operador conservar, restaurar y probar los servicios de mayor valor por separado. Un LXC de Home Assistant puede tener copias de seguridad frecuentes, mientras que un panel reemplazable puede tener una política de retención más corta. El calendario de copias puede seguir la frecuencia y las consecuencias de los cambios, en lugar de tratar todas las aplicaciones por igual.
El coste es la orquestación. Restaurar cinco LXC puede requerir el orden de inicio correcto, direcciones fijas, registros DNS, montajes de almacenamiento, certificados y credenciales de servicio. Una copia de seguridad que captura cada invitado por separado no conserva automáticamente el grafo de dependencias entre ellos.
El flujo de trabajo de Proxmox Backup Server de ZimaSpace puede proteger tanto VM como contenedores. La decisión sobre el empaquetado sigue siendo tuya: define qué servicios deben compartir un mismo punto de recuperación y cuáles deben poder recuperarse de forma independiente.
Las actualizaciones revelan el verdadero alcance de los fallos
Dentro de una única VM de Docker, una actualización del sistema operativo, un cambio en el daemon de Docker, un cambio en iptables o nftables, un evento de disco lleno o un problema del sistema de archivos puede detener todos los contenedores. Docker mantiene separado el empaquetado de las aplicaciones, pero el kernel invitado, el daemon, el controlador de almacenamiento y la pila de red siguen siendo compartidos.
Separar los LXC traslada muchos de esos cambios a invitados más pequeños. Una aplicación puede usar una versión de paquete diferente o un calendario de reinicios distinto sin modificar el entorno de todos los demás servicios. Esto resulta útil para aplicaciones expuestas públicamente, software experimental o servicios con ciclos de actualización frecuentes.
Sin embargo, todos los LXC siguen compartiendo el kernel del host de Proxmox. Un fallo del kernel del host, del almacenamiento, del puente de red o de Proxmox sigue siendo un evento común. Un LXC por aplicación reduce el alcance de los fallos en el nivel invitado, pero no crea independencia del host.
Las bases de datos y los proxies compartidos pueden definir una agrupación mejor que «una aplicación»
Las aplicaciones suelen estar compuestas por varios componentes: servicio web, base de datos, caché, trabajador, programador y ruta del proxy. Separar cada componente en un LXC distinto puede dificultar la recuperación habitual, porque el estado coherente de la aplicación se extiende por varios invitados.
Una unidad más adecuada puede ser un LXC por pila de aplicaciones, con Docker Compose dentro de ese LXC para los componentes estrechamente relacionados. Otra opción es una VM de Docker para servicios relacionados de bajo riesgo y LXCs separados para bases de datos, aplicaciones públicas o cargas de trabajo que dependan del hardware.
El debate de la comunidad de Proxmox sobre cuántas aplicaciones corresponden a cada invitado refleja la realidad práctica: la separación debe seguir las necesidades de dependencia, seguridad y recuperación, no una cantidad universal de aplicaciones.
El almacenamiento persistente determina si la copia de seguridad está completa
Una copia de seguridad de una VM puede capturar los discos virtuales, pero excluir los montajes bind de NAS, los recursos compartidos NFS externos, el almacenamiento transferido directamente o las copias de seguridad de las aplicaciones almacenadas en otro lugar. Una copia de seguridad de un LXC puede capturar su sistema de archivos raíz, mientras que los conjuntos de datos montados mediante bind permanecen fuera del archivo. Ninguna de las dos arquitecturas garantiza una recuperación completa simplemente porque el trabajo de Proxmox informe de que se ha realizado correctamente.
Haz un inventario de los archivos de Compose, secretos, bases de datos, contenido subido, certificados, montajes externos y destinos de las copias de seguridad. Indica si cada ruta está dentro de la copia de seguridad de la VM o del LXC, protegida por una instantánea independiente o se reconstruye a partir de la configuración.
Este es el límite: si el estado persistente de las aplicaciones reside en una única ruta compartida sin protección, cambiar el número de invitados no mejorará la recuperación. Corrige el límite de los datos antes de optimizar la granularidad de las copias de seguridad.
Ejecuta un simulacro de fallo para ambos diseños
- Enumera todas las aplicaciones, dependencias compartidas, rutas persistentes y montajes externos.
- Define la interrupción máxima aceptable y la pérdida de datos máxima para cada servicio.
- Restaura la VM completa de Docker con un nuevo ID de invitado y verifica toda la pila.
- Restaura un LXC representativo sin modificar las aplicaciones no relacionadas.
- Prueba el orden de inicio, el DNS, los certificados, el acceso a la base de datos y la disponibilidad de los puntos de montaje.
- Interrumpe intencionadamente la actualización de un invitado y observa qué servicios dejan de funcionar.
- Repite la recuperación utilizando únicamente la documentación escrita.
Mide tanto los pasos del operador como el tiempo de restauración. Un archivo LXC pequeño no es más sencillo desde el punto de vista operativo si recuperarlo requiere reconstruir diez relaciones no documentadas. Una copia de seguridad de una máquina virtual más grande no es más segura si revertirla elimina cambios válidos de todas las aplicaciones.
¿Qué distribución de invitados se adapta a la pila de aplicaciones?
Elige una única máquina virtual con Docker cuando
Elige una única máquina virtual cuando las aplicaciones compartan infraestructura, se mantengan juntas y puedan aceptar un único punto de copia de seguridad y reversión. Mantén explícitas las rutas de datos persistentes, añade copias de seguridad de las bases de datos específicas de cada aplicación y supervisa la máquina virtual compartida como una plataforma crítica.
Elige un LXC por aplicación o pila de aplicaciones cuando
Elige LXC independientes cuando los servicios tengan requisitos diferentes de riesgo, confianza, acceso al hardware, actualizaciones o retención. Agrupa los componentes estrechamente acoplados y automatiza la configuración base común para que el aislamiento no se convierta en trabajo manual repetitivo.
Usa una distribución híbrida cuando
Coloca los servicios de Docker relacionados y de bajo riesgo en una única máquina virtual, mientras aíslas las aplicaciones públicas, las bases de datos, Home Assistant o las cargas de trabajo dependientes del hardware en LXC o máquinas virtuales dedicados. Esto suele proporcionar límites más útiles que aplicar una única arquitectura a todos los servicios.
Preguntas frecuentes
¿Un LXC por aplicación elimina la necesidad de Docker?
No. Un LXC puede ejecutar un paquete nativo o alojar una pequeña pila de Docker Compose. LXC define el límite del invitado en Proxmox; Docker define el empaquetado de las aplicaciones dentro de ese límite. Resuelven problemas distintos de aislamiento y despliegue.
¿Es más fácil hacer copias de seguridad de una única máquina virtual grande?
Es más fácil programarlo y restaurarlo como un único objeto, pero el archivo es más grande y la reversión afecta a todas las aplicaciones. Es posible que aún se necesiten copias de seguridad independientes de las aplicaciones para las bases de datos y los datos montados externamente.
¿Se pueden migrar los LXC entre nodos de Proxmox?
Sí, pero es posible que haya que recrear las asignaciones de dispositivos, los montajes bind locales, los controladores del host, las rutas de almacenamiento y las suposiciones de red. El sistema de archivos raíz puede trasladarse con más facilidad que todo el contrato de hardware y almacenamiento.
Veredicto final
Usa una única máquina virtual con Docker cuando las aplicaciones formen realmente una sola plataforma y deban respaldarse, actualizarse y restaurarse juntas. Usa LXC independientes cuando los servicios necesiten puntos de recuperación independientes y dominios de fallo más pequeños a nivel de invitado. La mejor distribución agrupa los servicios según el estado compartido y la responsabilidad de recuperación, en lugar de elegir ciegamente un invitado por icono.
Productos recomendados
Comparaciones de productos
Más para leer
Servidor WireGuard frente a VPN de malla para dispositivos detrás de CGNAT
Usa una VPN de malla para dispositivos itinerantes sin complicaciones; usa un relay de WireGuard cuando quieras controlar el enrutamiento, las claves y el...
NAS de 10 GbE con clientes Gigabit: ¿actualizar primero el servidor o los dispositivos finales?
Actualiza la ruta del endpoint para una estación de trabajo lenta; actualiza primero el enlace ascendente del NAS cuando varios clientes gigabit lo saturen...
1GbE vs 2.5GbE para un servidor doméstico: ¿Qué cargas de trabajo marcan la diferencia?
Mantén 1GbE para servicios ligeros y transmisiones individuales; cambia a 2,5GbE cuando las transferencias recurrentes o los clientes combinados superen de forma sostenida aproximadamente...
