Actualizar un servidor sin tiempo de inactividad
Un servidor no puede quedarse sin actualizaciones, pero cada actualización supone el riesgo de detener la web. Ese riesgo se controla con un proceso: los parches de seguridad menores se instalan de forma automática, los cambios importantes se hacen según un plan, con snapshot, comprobación y reversión preparada, y los reinicios se agrupan en una ventana de mantenimiento. Veamos cómo organizarlo en un solo VPS.
Las actualizaciones de un servidor son de dos tipos, y cada uno se trata de forma distinta. Los parches de seguridad salen con frecuencia, cambian poco y casi nunca rompen nada: lo mejor es instalarlos automáticamente el mismo día. Las actualizaciones planificadas (una nueva versión del sistema, de PHP, de la base de datos o del panel) cambian el comportamiento de los programas, así que se preparan y se comprueban. La web suele caerse no por la actualización en sí, sino porque un cambio importante se instaló como si fuera menor.
Actualizaciones de seguridad automáticas
En Ubuntu Server, el paquete unattended-upgrades viene instalado y activado por defecto: una vez al día instala solo las actualizaciones de seguridad, y el resto de orígenes del archivo /etc/apt/apt.conf.d/50unattended-upgrades están comentados. La frecuencia se define en 20auto-upgrades y el registro se guarda en /var/log/unattended-upgrades/. Debian usa el mismo paquete, pero en una instalación mínima puede no estar; cómo activarlo se explica en la página de la Debian Wiki.
En AlmaLinux y otros sistemas compatibles con RHEL, esa misma tarea la cumple dnf-automatic. Por defecto no instala las actualizaciones: en /etc/dnf/automatic.conf se indican upgrade_type = security y apply_updates = yes, y después se activa el temporizador dnf-automatic.timer.
Ninguna de las dos herramientas reinicia el servidor por defecto. Es lo correcto: un servidor no debe reiniciarse en hora punta. Pero tampoco hay que olvidarse del reinicio, porque el kernel y las bibliotecas actualizados solo empiezan a funcionar tras reiniciar. En Ubuntu y Debian, el archivo /run/reboot-required indica que hace falta reiniciar; en AlmaLinux, el comando dnf needs-restarting -r. Conviene añadir esa comprobación a la monitorización del servidor y hacer el reinicio en la ventana de mantenimiento.
Snapshot antes de una actualización planificada
Antes de cualquier cambio importante se hace una instantánea del disco (snapshot) en el panel del proveedor. Permite devolver el servidor a su estado anterior en minutos si la actualización sale mal. Según el catálogo de accsly.io (noviembre de 2026), 1644 de los 2247 proveedores de VPS describen sus condiciones de copias de seguridad, y 318 mencionan expresamente las snapshots. Si el proveedor no ofrece snapshots, antes de actualizar hace falta una copia de seguridad completa cuya restauración ya haya probado.
Dos salvedades. La snapshot suele guardarse en el mismo sitio que el disco del servidor y no sustituye a una copia de seguridad: si falla el almacenamiento, se pierden las dos. Además, la snapshot de una base de datos en funcionamiento puede quedar inconsistente, así que antes se hace un volcado de la base o se detiene la escritura durante un momento. Cómo organizar las copias de seguridad en conjunto se explica en el artículo Copias de seguridad de un VPS: estrategias y herramientas; los planes con espacio para copias están en la página VPS para copias de seguridad.
Blue-green y actualización escalonada en un solo VPS
Los esquemas sin tiempo de inactividad vienen de los sistemas grandes, con varios servidores detrás de un balanceador: blue-green mantiene dos copias completas y pasa el tráfico de una a otra, y la actualización escalonada (rolling) retira los servidores del servicio de uno en uno. En un solo VPS, las mismas ideas se aplican a la aplicación, aunque no al propio sistema.
- Directorios de versiones. Cada versión de la web se despliega en su propio directorio, por ejemplo
releases/2026-11-07, y el servidor web apunta al enlace simbólicocurrent. La versión nueva se prepara al lado (dependencias, compilación, caché) y luego se cambia el enlace con un solo comando. Revertir consiste en volver a apuntar el enlace al directorio anterior. - Dos instancias de la aplicación. La versión nueva se arranca en otro puerto o en otro contenedor, se comprueba y después se cambia nginx a ella. Recargar la configuración de nginx no corta las conexiones: según la documentación de nginx, el proceso maestro primero comprueba la configuración y, si hay un error, sigue funcionando con la anterior, y los procesos de trabajo antiguos terminan de atender a sus clientes. Aun así, antes se ejecuta
nginx -t. Cómo ejecutar aplicaciones en contenedores se explica en el artículo Docker en un VPS: por dónde empezar. - Migraciones de base de datos compatibles. Mientras funcionan las dos versiones, la base de datos debe servir a ambas. Por eso los cambios de esquema se dividen en pasos: primero se añaden las columnas y tablas nuevas, se despliega el código que las usa y solo en la versión siguiente se elimina lo antiguo.
Actualizar el propio sistema a una nueva versión principal sin tiempo de inactividad en un solo servidor no es posible. Es más fiable levantar un segundo VPS con el sistema nuevo, trasladar a él la web, comprobarla y cambiar el DNS, tras reducir de antemano el TTL de los registros; cómo hacerlo se explica en el artículo Dominios y DNS para el propietario de un servidor. Para el segundo servidor, mientras dura la migración, resulta práctico el pago por horas. Cómo elegir la versión del sistema para que estas migraciones sean menos frecuentes, en el artículo Distribuciones Linux para un servidor: Ubuntu, Debian, AlmaLinux.
Actualizar el kernel sin reiniciar
El parcheo en caliente del kernel (live patching) corrige vulnerabilidades críticas en el kernel en ejecución sin reiniciar el servidor. En Ubuntu es Livepatch, incluido en la suscripción Ubuntu Pro: para uso personal es gratuito en hasta cinco máquinas. Para los sistemas compatibles con RHEL existen mecanismos propios, entre ellos servicios comerciales.
La tecnología tiene límites. Solo se pueden parchear las funciones que el kernel puede trazar, una limitación descrita en la documentación del kernel de Linux, así que parte de las correcciones solo llegan con un kernel nuevo. Canonical indica expresamente que Livepatch no elimina los reinicios planificados, sino que solo permite aplazarlos hasta la ventana de mantenimiento. Y lo más importante para un VPS: solo la virtualización KVM tiene kernel propio. En OpenVZ y LXC el kernel es compartido y lo actualiza el proveedor; más detalles en el artículo KVM u OpenVZ: cuál elegir.
Ventana de mantenimiento y reversión
La ventana de mantenimiento es un horario elegido de antemano con el menor número de visitas, normalmente la noche en la zona horaria del público principal, en el que se permiten reinicios y cambios planificados. El horario se saca de las estadísticas de la web, no al azar. Si la web la usan clientes o empleados, se les avisa con antelación. La ventana no es solo cosa suya: el proveedor también realiza trabajos, y cómo los comunica se analiza en el artículo SLA y uptime: qué prometen los proveedores.
El plan de reversión se prepara antes de empezar, no cuando algo ya se ha roto:
- defina de antemano las señales de fallo (errores en los logs, aumento del tiempo de respuesta, una comprobación fallida de las páginas clave) y el plazo a partir del cual revierte sin más intentos de arreglarlo;
- para el código, vuelva a apuntar el enlace o nginx a la versión anterior;
- para los paquetes, en AlmaLinux existe
dnf history undo, que deshace la última transacción; en Ubuntu y Debian no hay una forma estándar de revertir paquetes, así que allí se recurre a la snapshot; - la snapshot restaura el disco entero, y todo lo que se escribió después (pedidos, mensajes, registros de usuarios) se perderá. Por eso, durante una actualización arriesgada, la web se pone en modo de mantenimiento o de solo lectura.
Después de actualizar, compruebe las páginas clave y los logs de errores y compare el tiempo de respuesta con el habitual. Si antes del lanzamiento hizo pruebas de carga, el mismo escenario tras una actualización importante mostrará enseguida si la web se ha vuelto más lenta.