Cómo actualizar Proxmox de forma segura
Escribir apt full-upgrade y esperar no es una estrategia. Lo que hace falta saber es qué paquete reinicia un servicio y cuál exige un reinicio, y tener preparado un camino de vuelta antes de actualizar. Esta página cubre dos cosas: una rutina de actualización segura que funciona en cualquier host Proxmox, y cómo Atlas convierte esa rutina en un único flujo.
Por qué las actualizaciones de Proxmox parecen arriesgadas
Las actualizaciones del kernel exigen un reinicio, y un reinicio detiene consigo cada VM y contenedor. Una actualización aplicada en el momento equivocado es una interrupción no planificada.
Un full-upgrade puede reiniciar servicios de red o almacenamiento en plena jornada. La salida de apt no dice qué paquete disparará qué.
Si el arranque falla, el siguiente paso es la consola. Sin una instantánea o una copia de seguridad tampoco hay camino de vuelta.
Una rutina de actualización segura
Con o sin Atlas, este orden funciona en cualquier host Proxmox:
Listar los paquetes pendientes y revisar las notas de la versión; los saltos de versión mayor se planifican por separado.
Clasificar el efecto de cada actualización: sin interrupción, reinicia un servicio, o requiere un reinicio.
Crear primero una instantánea o copia de seguridad: una instantánea ZFS/Btrfs tarda segundos; una copia de seguridad PBS es aún mejor.
Ejecutar primero un dry-run cuando sea posible; ver qué cambia antes de aplicar nada.
Agrupar las actualizaciones que requieren reinicio en una ventana de mantenimiento; observar el primer arranque.
Verificar después: VM activas, pools de almacenamiento saludables, red en su lugar.
Atlas convierte esta rutina en un único flujo
Cada paso anterior está integrado en el producto:
Tres grupos de efecto
Cada paquete llega etiquetado con uno de tres grupos: Sin interrupción, Reinicia servicio, Reinicio requerido. Queda claro en qué se está haciendo clic.
Vista previa de dry-run
El cambio se ve en un dry-run antes de aplicarlo; las sorpresas ocurren en pantalla, no en el servidor.
Instantánea primero
El flujo crea un punto de restauración antes de actualizar; si algo sale mal, el camino de vuelta ya está ahí.
Boot guard
Fijación de kernel y boot guard: se mantiene a mano un kernel conocido como funcional frente al escenario de sistema que no arranca.
Un cerebro de actualización
El advisor indica qué se puede esperar y qué debe ir primero; la lista llega ordenada para facilitar la decisión.
Watch lo vigila
Atlas Watch monitorea continuamente la salud del host; si algo crítico ocurre tras una actualización, llega el aviso.
Preguntas frecuentes
- ¿Es seguro unattended-upgrades en Proxmox?
- Para parches de seguridad, sí. Dejar los paquetes de kernel y Proxmox en automático es arriesgado: un paquete que exige reinicio puede detener las VM sin previo aviso. Automatizar el repositorio de seguridad y actualizar el resto a mano, en una ventana, es el camino equilibrado.
- ¿Toda actualización de Proxmox requiere un reinicio?
- No. La mayoría de los paquetes no son disruptivos; algunos solo reinician su propio servicio. Los reinicios suelen ser necesarios para actualizaciones de kernel, systemd y microcódigo. Lo que importa es saber cuál es cuál antes de aplicar.
- apt upgrade frente a apt full-upgrade: ¿cuál es la diferencia?
- upgrade nunca instala nuevas dependencias ni elimina paquetes; full-upgrade hace ambas cosas cuando es necesario. Proxmox espera oficialmente full-upgrade (o pveupgrade); un simple upgrade puede dejar estados mixtos, aplicados a medias.
- ¿Cómo revierto una actualización rota?
- Con una instantánea ZFS/Btrfs o una copia de seguridad PBS tomada antes de actualizar, la vuelta atrás son minutos. Sin ella, toca elegir un kernel más antiguo en GRUB y degradar paquetes a mano. Por eso el punto de restauración va antes de la actualización.
- ¿Con qué frecuencia debo actualizar Proxmox?
- Los parches de seguridad no se retrasan; las actualizaciones de funciones se agrupan en ventanas semanales o mensuales. Cuando aparece un CVE crítico, no se espera a la ventana.
- ¿Una actualización de versión mayor (digamos, de 8 a 9) es diferente?
- Sí. Una actualización mayor es un procedimiento propio: la guía oficial de actualización, una herramienta de comprobación previa como pve8to9, y una copia de seguridad completa son obligatorias. No se mezcla con el flujo de actualización rutinario.
- ¿Cuáles son las buenas prácticas para las actualizaciones de Proxmox?
- Las buenas prácticas de actualización de Proxmox se resumen en unas pocas cosas: leer qué va a cambiar, hacer una instantánea de las máquinas que importan, planificar aparte los paquetes que exigen reinicio y comprobar que el sistema vuelve de verdad tras una actualización del núcleo. Atlas asume ese orden: clasifica el efecto de cada paquete, toma la instantánea de antemano y con la guardia de arranque mantiene abierto el camino de vuelta al núcleo anterior.
Entradas relacionadas
- Antes de pulsar actualizar: qué actualización detiene qué Lo que temen quienes llevan meses sin actualizar no es la actualización, es no saber qué se va a detener. Las actualizaciones no son una sola cosa y sus efectos no se parecen en nada.
- Los repositorios y el aviso de suscripción: la primera sorpresa tras instalar En una instalación nueva la actualización falla con un error de autenticación y no hay nada roto: el repositorio por defecto es el de pago. Esta entrada cubre los repositorios, la diferencia real entre ellos y la peligrosa orden de una línea que circula por los foros.
- Actualización del núcleo: por qué la actualización más peligrosa es la más silenciosa El núcleo se instala, no pasa nada, todo parece normal. El peligro llega en el siguiente arranque, y ese arranque puede estar a semanas. Entre causa y efecto se meten semanas.
- Algo se rompió tras la actualización: "después" y "por culpa de" no son lo mismo Un reinicio es la primera prueba honesta de todo lo hecho desde el reinicio anterior. Parte de lo que se rompe no lo trajo la actualización, ya estaba ahí y nunca se había puesto a prueba.