Quedarse sin espacio es la causa más frecuente de que un servidor deje de funcionar sin la menor malicia de por medio. El sitio devuelve 500, la base de datos no escribe, el correo no sale, y df -h mientras tanto informa de varios gigabytes libres. Repasemos los tres casos en que eso ocurre y, de paso, lo que conviene saber sobre SMART.

Caso uno: se acabaron los inodos

Un sistema de archivos guarda dos recursos limitados: espacio para el contenido y registros sobre los archivos. El segundo se agota con independencia del primero:

df -h
df -i

Si IUse% en el segundo comando es 100, la cosa va de inodos. Hay espacio, pero no se puede crear un solo archivo, ni siquiera vacío.

Los culpables son siempre los mismos: millones de archivos diminutos. Las sesiones de PHP en /var/lib/php/sessions cuya recolección se ha roto. Una caché de aplicación que nunca se limpia. Una cola de correo atascada. Un directorio de miniaturas. Se encuentran así:

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

El comando enumera los directorios con más archivos. En un sistema grande tarda minutos: es normal.

Caso dos: el archivo está borrado y el espacio no vuelve

Situación más traicionera. Alguien borró con rm un registro desmesurado, pero el proceso que escribía en él lo mantiene abierto. El archivo ya no está en el directorio, el espacio sigue ocupado, y así será hasta que el proceso se reinicie.

sudo lsof +L1

El comando muestra los archivos sin referencia en el sistema de archivos pero aún retenidos por un proceso. La cura es reiniciar o recargar con suavidad ese proceso, no buscar «adónde han ido los gigabytes».

De ahí la regla: un registro desmesurado no se borra, se vacía, y así el descriptor abierto sigue siendo utilizable:

sudo truncate -s 0 /var/log/huge.log

E inmediatamente después se configura la rotación; si no, todo se repetirá en una semana.

Caso tres: se lo comieron los registros

Adónde ha ido exactamente el espacio se ve bajando nivel a nivel:

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

La opción -x impide salir a otros sistemas de archivos; sin ella la cuenta se mete en /proc y en los montajes de red. Todo esto resulta más cómodo en ncdu, si está disponible.

Los devoradores habituales:

  • journald. Un comando lo resuelve: journalctl --disk-usage. Se limita con la línea SystemMaxUse=500M en /etc/systemd/journald.conf y se purga una vez con journalctl --vacuum-size=200M;
  • los registros de las herramientas de seguridad. Suricata con su configuración estándar escribe treinta tipos de eventos y no se configura rotación alguna: en un servidor real eso dio 15 GB en dos días. Lo mismo pasa con audit.log y con los registros de depuración de nginx;
  • las copias de seguridad guardadas en el mismo disco y nunca eliminadas;
  • la caché de apt: apt clean devuelve a veces un par de gigabytes.

Unas palabras sobre /boot

Una partición pequeña que se llena de núcleos antiguos. Por sí sola no tira el sitio, pero detiene en seco las actualizaciones: el núcleo nuevo no se instala y detrás se atasca toda la cola de paquetes. Se arregla con apt autoremove --purge y se previene activando la eliminación automática de núcleos sin usar en los ajustes de actualizaciones automáticas.

SMART: qué atributos importan

Primero una salvedad: en un servidor virtual SMART no suele estar disponible, porque el disco es virtual y usted no ve el físico que hay debajo. No es una avería, sencillamente no hay datos. Todo lo que sigue se refiere a servidores dedicados y a hardware propio.

sudo smartctl -a /dev/sda

La línea SMART overall-health self-assessment test result: PASSED no es motivo para relajarse: se mantiene en verde prácticamente hasta el fallo. Lo que hay que mirar son los contadores concretos:

  • 5, Reallocated_Sector_Ct: sectores reasignados. Que no sea cero significa que el disco ya se está degradando; si crece, cámbielo sin demora;
  • 197, Current_Pending_Sector: sectores ilegibles a la espera de decisión. El más alarmante de todos: suele significar que parte de los datos ya no se puede recuperar;
  • 198, Offline_Uncorrectable: lo mismo, confirmado por una comprobación;
  • SSD: Percentage Used / Media_Wearout_Indicator: la resistencia de escritura consumida. Una magnitud previsible, sobre la que se planifica el reemplazo.

La temperatura y las horas de funcionamiento, en cambio, no dicen nada por sí solas: un disco con cinco años de servicio y contadores de error a cero es más fiable que uno nuevo con un 1 en el atributo 197.

El sentido de la vigilancia

Todo lo anterior es una reacción a lo ya ocurrido. Sin embargo, tanto el llenado de un disco como el desgaste de un SSD son procesos lentos y perfectamente previsibles: una curva de ocupación de dos semanas señala la fecha en que se acabará el espacio mucho antes de que suceda. La diferencia entre «el sitio lleva caído desde las tres de la madrugada» y «el jueves hay que limpiar los registros» consiste únicamente en tener la cifra a la vista. Cómo se ve todo reunido lo muestra la página de demostración de abajo.