En entornos de hosting compartido, miles de cuentas y aplicaciones generan millones de archivos pequeños. Cuando el sistema de archivos agota sus inodos, el servidor no puede crear nuevos archivos aunque todavía haya espacio libre: se desencadena un bloqueo de escritura que afecta a correos, sitios WordPress y procesos cron. Este artículo explica, desde la práctica operativa, cómo gestionar inodos para prevenir bloqueos: monitorización, diseño de particiones, quotas, elección de filesystem, limpieza automatizada y recomendaciones específicas para WordPress y mail.

Qué son los inodos y por qué importan en hosting compartido

Un inode (inodo) es una estructura del sistema de archivos que guarda metadatos de un archivo: permisos, propietario, timestamps y punteros a bloques. Sistemas como ext4 reservan un número fijo de inodos al formatear la partición. Si se consumen todos, el kernel impide crear archivos aunque haya espacio libre en disco. En hosting compartido esto sucede con frecuencia por:

• Millones de archivos temporales o cachés (plugins de WordPress, caches de sistema).
• Maildirs con gran cantidad de correos separados en archivos individuales.
• Backups locales, extractos de logs o snapshots mal gestionados.
• Muchos usuarios subiendo pequeños assets (SVG, thumbnails, ficheros de sesión).

Detección rápida y análisis de usuarios afectados

Lo primero es detectar y priorizar. Usa estas comprobaciones básicas desde la consola:

• Comprobar uso global de inodos: df -i.
• Ver detalle del filesystem y parámetros de inodos: tune2fs -l /dev/sdXN | grep -i inode (ext4).
• Identificar directorios con más archivos: ejemplo práctico:

for d in /home/*; do echo $(find "$d" -type f 2>/dev/null | wc -l) $d; done | sort -rn | head -n 20

Este script lista las 20 cuentas con más archivos y ayuda a localizar cuentas que consumen inodos. Para una vista por directorio de nivel superior:

find /home -xdev -printf '%h\n' | sort | uniq -c | sort -rn | head

Estrategias para prevenir agotamiento de inodos

1. Selección de sistema de archivos

La elección del filesystem es crítica:

• ext4: popular, pero usa inodos fijos creados al formatear. Para entornos con muchos archivos pequeños hay que calcular la ratio inodo al crear la partición (mkfs.ext4 -i bytes-per-inode).
• XFS: maneja inodos de forma más flexible y es recomendado para hosting con millones de archivos; ofrece mejor escalabilidad y rendimiento en metadata.
• Btrfs: avanzado, pero consume CPU y puede no ser ideal en hosting compartido tradicional. Evaluar caso por caso.

2. Crear el filesystem con la ratio adecuada

Si vas a formatear, ajusta la relación bytes/inodo (ext4):

mkfs.ext4 -i 16384 /dev/sdX1

Valores menores crean más inodos (útil para muchos ficheros pequeños), pero aumentan overhead. Para sistemas existentes, la única solución segura para cambiar la cantidad de inodos es respaldar, recrear y restaurar.

3. Cuotas de inodos por usuario

Implementa cuotas (block + inode) para proteger el servicio de usuarios que consuman recursos desproporcionados.

setquota -u usuario 100000 120000 10000 12000 /home

La sintaxis es: setquota -u usuario block-soft block-hard inode-soft inode-hard filesystem. CloudLinux ofrece límites por usuario preconfigurados y análisis del uso de inodos en paneles, muy útil en hosting compartido.

4. Offloading y cambios en la arquitectura de aplicaciones

• Offload de uploads a object storage (S3, Wasabi) o CDN para reducir ficheros en disco.
• Para WordPress, usar almacenamiento externo para medios (WP Offload Media) y object cache con Redis o Memcached para evitar caches basados en archivos.
• Configurar plugins que escriban menos ficheros: preferir caches memoria/redis frente a archivos.

5. Limpieza y retención inteligente

Automatiza limpieza de ficheros temporales y caches antiguos con políticas claras.

• Ejemplos de cron para limpieza:

# borrar archivos temporales de más de 3 días
find /home/*/tmp -type f -mtime +3 -delete

# limpiar cachés de WordPress con extensiones que soporten cron
wp cache flush --path=/home/usuario/public_html

6. Rotación de logs y backups externos

Configura logrotate correctamente y evita backups locales interminables. Mantén backups incrementales en almacenamiento externo y elimina snapshots antiguos.

Monitorización y alertas: cómo definir umbrales útiles

La monitorización es clave: no esperes a que el sistema llegue al 100% de inodos. Sugerencias:

• Alertas al 70–80% de uso de inodos por filesystem.
• Alertas por usuario que supere X% del total de inodos de /home (configurable).
• Integrar métricas en Prometheus / Grafana con node exporter para visualizar node_filesystem_files y node_filesystem_files_free. Ejemplo de query Prometheus:

(1 - node_filesystem_files_free / node_filesystem_files) * 100 > 80

Para Nagios/Zabbix usar check_disk con opción de inodes o scripts personalizados que cuenten ficheros por cuenta.

Caso práctico: WordPress en hosting compartido

WordPress es a menudo el culpable: themes, plugins y caches generan muchos ficheros. Acciones concretas:

• Usar object cache (Redis) y no cache de disco (si el host lo permite).
• Offload de medias a S3/Cloudinary y servir con CDN.
• Limitar revisiones de posts y controlar plugins que generan ficheros (backups locales, debug logs, etc.).
• Configurar wp-cron desactivado y usar cron del servidor para evitar ráfagas de procesos que generan ficheros temporales.

Recuperación ante agotamiento de inodos

Si ocurre un bloqueo de escritura:

• Actuar rápido: identificar cuentas con más archivos y limpiar temporales y caches.
• Deshabilitar servicios que generan ficheros masivos (por ejemplo: cron de backup, plugins de backup, procesos de indexing).
• Si es recurrente, planificar re-particionado con un filesystem adecuado y/o aumentar la cantidad de inodos recreando la partición.

Recomendaciones operativas finales

• Diseñar particiones separadas (/home, /var, /tmp) para aislar consumos.
• Habilitar cuotas y límites por usuario (quota / CloudLinux / LVE) en hosting compartido.
• Elegir XFS para entornos con millones de ficheros pequeños y ext4 con ratio de inodo ajustado si se usa ext4.
• Automatizar limpieza y revisar semanalmente el top consumidores de inodos.
• Educar clientes: recomendaciones en el panel sobre uso de backups locales y plugins intensivos.

Conclusión

La gestión eficiente de inodos en hosting compartido combina arquitectura (elección del filesystem y particionado), políticas (cuotas, límites por usuario), cambios en la aplicación (offload de media, caches en memoria) y operaciones proactivas (monitorización, limpieza automática y alertas). Con estas prácticas puedes evitar bloqueos de escritura que causan interrupciones del servicio y degradación de la experiencia del cliente. Planifica capacidad, automatiza detección y respuesta, y prioriza soluciones que reduzcan la creación masiva de ficheros: son las palancas que más impacto tienen en entornos compartidos.