Checklist de mantenimiento para un servidor Linux

Qué significa realmente mantener un servidor Linux

El mantenimiento de un servidor Linux consiste en una lista breve de comprobaciones que se ejecutan con una frecuencia fija. No es un proyecto que termina. Cada semana, confirme que las actualizaciones se instalaron, que el disco tiene espacio, que ningún servicio se detuvo y que el trabajo de backup terminó. Cada mes, pruebe una restauración, compruebe la fecha de expiración de los certificados, audite las cuentas y las claves, y elimine los kernels y registros antiguos. Una vez por cada versión de la distribución, planifique la actualización de versión y realice el reinicio que sigue posponiendo.

Crear el servidor es otra tarea, y los primeros diez minutos en un VPS nuevo cubren esa parte. Esta página trata del año siguiente. Cada elemento que aparece a continuación indica el fallo que evita, porque una lista de comprobación sin consecuencias es una lista que la gente deja de ejecutar en silencio.

Los comandos de aquí son ilustrativos y deben leerse antes de ejecutarlos. Compare su salida con la del servidor, porque un valor saludable de espacio libre o de cantidad de procesos depende de la función del equipo. Cuando una comprobación varía entre distribuciones, el texto lo indica. Los ejemplos usan Debian y Ubuntu con apt. En la familia RHEL, la herramienta es dnf y varias rutas son diferentes.

Cómo elegir una frecuencia de mantenimiento de servidores Linux que pueda mantener

Las comprobaciones semanales cubren los elementos que cambian sin intervención: paquetes, uso del disco, estado de los servicios y tareas programadas. Estos elementos cambian por sí solos, por lo que una semana es aproximadamente el máximo tiempo que puede dejarlos sin revisar.

Las comprobaciones mensuales cubren el deterioro gradual: certificados próximos a caducar, cuentas que nadie eliminó, kernels que se acumulan en /boot y archivos de registro que superan una regla de rotación que dejó de coincidir. Nada de esto falla mañana. Todo acaba fallando.

Las comprobaciones de las versiones se basan en el calendario. Una versión de la distribución es el único elemento de mantenimiento con un plazo externo, porque el soporte de la versión actual termina tanto si está preparado como si no.

Fije un horario para ejecutar estas tareas: el lunes por la mañana para la revisión semanal y el primer día del mes para la mensual. Ejecutar una lista de comprobación «cuando tenga tiempo» no es una lista de comprobación. Cuando administre más de unos pocos equipos, ejecute estas tareas desde un único lugar en vez de hacerlo manualmente. Ese es el tema de administrar varios servidores Linux desde un único lugar.

Semanalmente: ¿las actualizaciones se instalaron realmente?

Habilitar unattended-upgrades no equivale a saber que se ejecutó. El servicio puede estar enmascarado, la configuración puede estar limitada a un origen que no utiliza y un paquete retenido puede impedir todas las ejecuciones posteriores. La instalación se explica en actualizaciones de seguridad automáticas en Ubuntu. La tarea semanal comprueba que la instalación haya realizado su trabajo.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable es la medida fiable porque informa del estado actual, no de la intención. Si las actualizaciones de seguridad siguen apareciendo en esa lista, la automatización no está funcionando. Por tanto, lea el registro antes de asumir que el equipo tiene todos los parches. Un paquete fijado con apt-mark hold se omite indefinidamente y no informa de nada. Por eso apt-mark showhold debe revisarse en la misma comprobación.

Esto evita el siguiente problema: ejecutar durante meses un paquete con vulnerabilidades conocidas mientras se cree que las actualizaciones son automáticas.

Semanal: margen disponible de disco e inodos

Un sistema de archivos raíz lleno provoca fallos que parecen no estar relacionados con el disco. La base de datos rechaza las escrituras, el registro deja de funcionar, una actualización de paquetes falla después de dejar el sistema configurado a medias y, en algunos entornos, no se puede abrir una sesión nueva porque no puede escribir sus propios archivos.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i es la mitad que la mayoría omite. Los inodos son estructuras de cantidad fija que contienen los metadatos de los archivos, y un sistema de archivos puede quedarse sin ellos aunque df -h siga mostrando gigabytes libres. Entonces las escrituras fallan con No space left on device junto a una salida que muestra espacio disponible. La primera vez, esto puede costar una hora de diagnóstico. Millones de archivos pequeños, procedentes de una cola de correo atascada o de un directorio de sesiones que nadie depura, son la causa habitual.

du -xh permanece en un solo sistema de archivos, que es lo que se necesita en un servidor con bind mounts o almacenamiento conectado. En un host Docker, la respuesta suele estar en las capas de imágenes y los volúmenes sin uso. Puede liberar ese espacio como se describe en depurar el uso de disco de Docker en un VPS.

El espacio libre indica la capacidad. El almacenamiento subyacente puede fallar según su propio ciclo. Es una comprobación independiente que se trata en monitorizar el estado del disco en un VPS.

Semanal: ¿qué se detuvo sin avisarle?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Una unidad que se bloqueó y alcanzó su límite de reinicios queda en estado fallido y permanece así, en silencio. Nadie le envía un correo por ello. list-timers es la parte más útil: muestra cuándo se ejecutó por última vez cada temporizador y cuándo se ejecutará de nuevo, por lo que un valor de LAST más antiguo que el propio intervalo del temporizador indica que esa tarea no se ejecutó.

Lea el journal de la unidad antes de reiniciarla con journalctl -u <unit> -n 100 --no-pager. Un reinicio elimina el síntoma y, después, ya no tendrá motivos para volver a revisarla hasta que ocurra lo mismo en un momento más inoportuno.

El fallo que esto evita: un agente de monitorización, un worker de colas o un servicio de copias de seguridad que lleva detenido desde un pico de memoria ocurrido hace tres semanas.

Semanalmente: ¿el trabajo de copia de seguridad terminó realmente?

Una copia de seguridad programada y una copia de seguridad completada son hechos distintos. Sólo una de ellas permite restaurar los datos. Compruebe que haya terminado.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

Confirme dos aspectos. La última ejecución terminó con código 0 y el archivo más reciente es reciente y tiene aproximadamente el tamaño esperado. Un archivo de copia de seguridad que de repente tiene una décima parte de su tamaño habitual corresponde a un volcado fallido que aun así escribió un archivo. Es la forma más peligrosa de fallo de una copia de seguridad porque todo lo posterior parece normal.

Si el script canaliza un volcado a un compresor, añada set -o pipefail al principio. Sin esta opción, el estado de salida de la canalización es el del compresor, y el compresor terminó correctamente: comprimió el mensaje de error. El trabajo informa de éxito todas las noches mientras escribe un archivo pequeño que no contiene datos.

Mensualmente: restaure una copia de seguridad en otro lugar

Este es el elemento que más personas omiten y el que determina si el resto de la lista era relevante.

Restaure en otra máquina o en un contenedor nuevo, nunca sobre los datos activos. Después, abra lo que restauró y confirme que es válido. Cuente las filas de una tabla. Abra un documento. Inicie sesión en la aplicación restaurada. Que una extracción haya terminado demuestra que el archivo es legible, pero nada más.

Las herramientas del repositorio tienen su propia verificación: restic check --read-data-subset=5% y borg check --verify-data leen los datos almacenados en lugar del índice. Ejecútelas y considérelas una prueba rápida, no un sustituto. La verificación comprueba que los bytes sobrevivieron. Una restauración comprueba que los bytes son los que necesita la aplicación.

Hay dos detalles que muchas personas aprenden por las malas. Pruebe la frase de paso de descifrado en una máquina que no tenga ya la clave en un agente, porque una copia de seguridad que no puede descifrar no es una copia de seguridad. También mida el tiempo de la restauración, porque esa duración es su tiempo real de recuperación y el momento habitual para descubrirlo es durante una interrupción del servicio.

Mensualmente: ¿qué certificados caducan pronto?

La automatización de la renovación puede fallar sin mostrar errores. El temporizador de certbot puede renovar el archivo en disco mientras el servidor web sigue sirviendo el certificado antiguo desde la memoria, porque no se ejecutó el deploy hook que recarga el servicio. Por eso, consulte desde fuera del servidor qué certificado está sirviendo el servidor activo.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

La opción -servername establece SNI (indicación del nombre del servidor). Es necesaria en cualquier dirección que aloje más de un sitio. De lo contrario, recibirá el certificado predeterminado en lugar del suyo. Si certbot se instaló desde un snap, el temporizador tiene otro nombre. Por eso, busque la palabra en lugar de asumir el nombre de una unidad.

Recuerde los certificados que no tienen ninguna automatización: los de un servidor de correo, una VPN o una autoridad certificadora interna. Esos son los que caducan durante un fin de semana. Los navegadores y los clientes los rechazan directamente en lugar de mostrar una advertencia.

Mensual: usuarios, acceso sudo y claves SSH

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T muestra la configuración efectiva después de combinar cada Include, que es la configuración que realmente usará el daemon. Las imágenes recientes de Ubuntu incluyen archivos de configuración adicionales en /etc/ssh/sshd_config.d/, y estos pueden sobrescribir el archivo principal. Por tanto, leer sólo sshd_config puede mostrar lo contrario de la configuración efectiva. En la familia RHEL, el grupo administrativo es wheel en lugar de sudo, así que ajuste la línea getent.

A continuación, lea los propios archivos authorized_keys. El acceso se concede mediante una clave, no mediante la cuenta. Por tanto, una clave que haya dejado un contratista que terminó su trabajo hace seis meses sigue permitiendo iniciar sesión y no aparecerá en ninguna lista de usuarios. Las claves incluyen un campo de comentario. Úselo y elimine todo lo que no pueda atribuir a una persona.

Para consultar el historial de inicios de sesión, journalctl -t sshd --since "30 days ago" | grep -i accepted busca el identificador de syslog, no el nombre de una unidad. Esto es importante porque Ubuntu 24.04 activa SSH mediante un socket. Por ello, cada conexión se registra en una unidad generada específica para esa conexión, y un journalctl -u ssh simple puede no mostrarla.

Mensualmente: kernels antiguos y un /boot lleno

/boot suele ser una partición independiente de unos cientos de megabytes en una imagen estándar de VPS. Cada actualización del kernel añade una imagen y un initramfs. Cuando se llena, la siguiente actualización falla a mitad del proceso y deja paquetes sin configurar. Es una situación problemática que puede aparecer por sorpresa un viernes.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r siempre es lo primero: indica el kernel que se está ejecutando ahora mismo y debe conservarse, independientemente de lo que elimine. apt autoremove gestiona el caso normal en Debian y Ubuntu, ya que los kernels están marcados como instalados automáticamente y el actual está protegido. Los casos especiales, como un kernel instalado manualmente o un /boot que ya está lo bastante lleno como para bloquear apt, se explican en eliminación de kernels antiguos en Ubuntu.

Mensual: crecimiento de los registros y el journal de systemd

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug es una simulación y no escribe nada, por lo que es segura en un servidor en producción. Conviene ejecutarla porque las reglas de rotación coinciden con las rutas: si una aplicación cambió la ubicación de sus registros durante una actualización, su propia regla deja de aplicarse y ese archivo crece sin límite hasta llenar el disco.

systemd limita el tamaño del journal, pero lo hace según una fracción del sistema de archivos y no según una cantidad que haya elegido. Establezca SystemMaxUse= en /etc/systemd/journald.conf y reinicie systemd-journald si quiere definir un límite concreto. sudo journalctl --vacuum-time=14d recupera espacio de inmediato, pero es una acción puntual y no una política, por lo que debe combinarlo con el cambio de configuración.

Por versión: el reinicio que sigue posponiendo

Un paquete de kernel actualizado en el disco no significa que el kernel esté ejecutándose. Hasta reiniciar, la máquina sigue usando el anterior. Además, el live patching, cuando está disponible, sólo cubre un subconjunto de las correcciones.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

Ese archivo indicador es una convención de Debian y Ubuntu que escriben los scripts de los paquetes. Los sistemas de la familia RHEL no lo crean. Allí, needs-restarting -r responde a la pregunta equivalente y procede de dnf-utils. needrestart, instalado de forma predeterminada en las imágenes recientes de Ubuntu Server, responde a un nivel inferior al kernel: muestra los procesos que todavía tienen asignada una biblioteca reemplazada en el disco. Por eso, una versión corregida de OpenSSL no surte efecto hasta que se reinician los servicios que la utilizan.

Programe el reinicio en lugar de evitarlo. En /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; y Unattended-Upgrade::Automatic-Reboot-Time "03:00";, deje la decisión para la hora que haya elegido. Un reinicio planificado también es la única forma de comprobar que el equipo vuelve a arrancar, porque una entrada fstab defectuosa o un servicio que nunca habilitó se manifiestan durante el arranque y en ningún otro momento.

Planificación de la actualización de la distribución por versión

Las versiones Ubuntu LTS tienen cinco años de soporte estándar y las versiones intermedias tienen nueve meses. Por tanto, esta decisión determina la carga de trabajo de las actualizaciones durante años. Esta diferencia se explica en versiones LTS frente a versiones intermedias en un servidor.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade lee ese archivo y Prompt=lts limita el proceso a las actualizaciones de LTS a LTS. La ruta de LTS a LTS normalmente se habilita con el primer lanzamiento puntual de la nueva versión, no el día del lanzamiento. Compruebe qué versión ofrece su máquina en lugar de planificar según una fecha supuesta. El procedimiento de la actualización se describe en actualizar Ubuntu 24.04 a 26.04.

Planifique un margen de tres meses. Cree una instantánea y compruebe que puede restaurarla. Enumere los repositorios apt de terceros. La actualización los deshabilita y cada uno necesita un destino nuevo para la nueva versión. Decida el procedimiento de reversión antes de empezar. En agosto de 2026, Ubuntu 24.04 LTS tiene soporte estándar hasta abril de 2029, por lo que se trata de una planificación y no de una emergencia.

Qué automatizar y qué mantener manual

Automatice las decisiones que ya ha tomado: actualizaciones de seguridad, rotación de registros, renovación de certificados y tareas de backup. Automatice también las alertas, porque una comprobación que depende de que usted la recuerde no se realizará a las 2 de la madrugada. Un monitor externo, como monitorización de estado autoalojada con Uptime Kuma, detecta lo único que ningún script del propio servidor puede informar: que el servidor no está accesible.

Mantenga dos tareas manuales: la prueba de restauración y la auditoría de cuentas. En ambas, una persona debe decidir si el resultado es correcto. Si prefiere consultar el estado del sistema en un navegador en lugar de usar un terminal, Cockpit frente a Webmin para la administración de servidores compara las dos consolas web habituales.

La automatización también necesita su propia comprobación. Por eso, el primer elemento semanal de esta lista consiste en verificar el actualizador. Una automatización que falla silenciosamente es peor que no tener ninguna, porque elimina al mismo tiempo el fallo y el hábito de revisar el resultado.

Todo el checklist en un solo lugar

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

¿Con qué frecuencia debo realizar el mantenimiento de un servidor Linux?

Cada semana, para todo lo que cambia por sí solo: estado de las actualizaciones, espacio disponible en disco y para inodos, unidades fallidas y confirmación de que el trabajo de copia de seguridad ha terminado. Cada mes, para los problemas que aparecen lentamente: una prueba de restauración, la caducidad de los certificados, la auditoría de cuentas y claves SSH, los kernels antiguos y el crecimiento de los registros. Una vez por cada lanzamiento de la distribución, para actualizar la versión y reiniciar con el kernel actual. La revisión semanal tarda unos minutos en un servidor en buen estado. Ese es el motivo para hacerla cada semana y no sólo cuando algo parece fallar.

¿Por qué debo probar una restauración si el trabajo de copia de seguridad informa de que ha terminado correctamente?

Porque el trabajo informa sobre su propio estado de salida, y ese estado puede ser correcto aunque el archivo sea inútil. Una descarga canalizada a un compresor sin set -o pipefail devuelve el estado del compresor. Por tanto, una descarga fallida que sólo haya generado un mensaje de error también termina con código cero y escribe un archivo pequeño. Restaure los datos en otra máquina, ábralos y cuente algún elemento. La restauración también mide su propia duración. Ese tiempo es su tiempo real de recuperación.

¿Tengo que reiniciar después de cada actualización del kernel?

Debe reiniciar antes de que el nuevo kernel sea el kernel en ejecución. En Debian y Ubuntu, la presencia de /var/run/reboot-required indica que un paquete lo solicitó, y /var/run/reboot-required.pkgs identifica cuál. En la familia RHEL ese archivo no existe, y needs-restarting -r de dnf-utils responde a la misma pregunta. Configure una ventana de reinicio automático en /etc/apt/apt.conf.d/50unattended-upgrades en lugar de posponerlo indefinidamente. Una máquina que no se ha reiniciado en un año tiene una ruta de arranque no probada y también un kernel antiguo.

¿Qué comprobaciones puedo automatizar de forma segura?

Automatice las acciones cuya decisión ya está tomada: actualizaciones de seguridad, rotación de registros, renovación de certificados y copias de seguridad programadas. Automatice también las notificaciones, para que una unidad fallida o un disco que se está llenando le avisen sin que una persona tenga que ejecutar un comando. Mantenga manuales la prueba de restauración y la auditoría de claves, porque cada una requiere que una persona determine si el resultado es correcto. Añada después una comprobación de la propia automatización, ya que un fallo silencioso del actualizador parece exactamente que todo funciona.