Revisar espacio en disco en cPanel, Plesk y DirectAdmin

Por qué el espacio en disco es el “suelo” de tu servidor (y cómo se rompe todo cuando se llena)

Comprobar el espacio en un servidor Linux es una tarea que todos sabemos que deberíamos hacer… pero muchas veces se pospone hasta que algo cruje. En mi día a día, lo trato como una rutina de salud del sistema. ¿Por qué? Porque todo descansa sobre el disco: bases de datos, logs, backups, correos, cachés y actualizaciones. Cuando ese “suelo” se llena, el fallo rara vez es amable: la base de datos deja de escribir, los logs se paran justo cuando más pistas necesitas, las colas de correo se bloquean y las actualizaciones se quedan a medias. Ahí aparece el pánico.

Lo más traicionero es que casi nunca ocurre de golpe. El uso crece a fuego lento: backups duplicados que nadie mira, directorios de logs sin rotación, buzones de correo que nadie limpia, plugins que sueltan temporales eternos. Si no miras, “no existe”. Hasta que el sistema te niega espacio y te enseña meses de polvo debajo de la alfombra.

Mi regla de oro: visualizar tendencia y actuar antes del 80–85 %. Con esa simple disciplina puedes mover backups a otro destino, rotar logs, revisar qué proyectos consumen más o planificar una ampliación con calma. Además, revisar espacio te obliga a conocer el servidor de verdad: empiezas a ver patrones repetidos (proyectos ruidosos, instalaciones obsoletas que siguen ocupando gigas, tablas de sesiones gigantes). Esa radiografía es oro.

Dónde mirar primero: logs, backups, correo y temporales (checklist rápido)

Cada vez que hago una revisión exprés empiezo por lo mismo:

1. Logs
   • Rutas típicas: /var/log/, logs de aplicaciones (storage/logs, logs/ de Node/PM2), journalctl (systemd).
   • Señales: ficheros .log de varios GB, históricos sin compresión, rotaciones mal configuradas.
   • Acciones seguras: comprimir históricos, ajustar logrotate, bajar niveles de debug en producción.
2. Backups
   • Rutas típicas: /backup, /home/usuario/backups, directorios de Plesk/cPanel.
   • Señales: duplicados, retenciones infinitas, snapshots locales “por si acaso”.
   • Acciones: mover a almacenamiento externo (S3/NFS), limitar retención, verificar que se purga lo antiguo.
3. Correo (Maildir)
   • Rutas típicas: mail/ o var/qmail/mailnames/ (según panel).
   • Señales: buzones con años de adjuntos, carpetas de spam o enviados gigantes.
   • Acciones: políticas de retención, limpieza de adjuntos pesados, archivado fuera.
4. Temporales y cachés
   • Rutas: /tmp, cachés de apps (WordPress wp-content/cache, Magento var/cache, Symfony var/cache).
   • Señales: miles de archivos pequeños (alerta de inodes), carpetas session sin TTL.
   • Acciones: limpiar temporales seguros, configurar expiración automática, revisar cronjobs.
5. Bases de datos
   • Señales: tablas de sesiones o logs de auditoría desbocadas, binlogs sin purgar.
   • Acciones: políticas de depuración, purga de binlogs con cuidado, índices sobre tablas crecientes.

En mi experiencia, estos cinco focos resuelven el 80 % de los sustos de disco sin tocar archivos críticos del sistema.

---

cPanel (usuario): usando Disk Usage y el Administrador de archivos (qué carpetas pesan y cómo decidir)

En cPanel, el punto de partida es Disk Usage (Uso de disco). Desde ahí obtienes un desglose por directorios con barras visuales. Mi flujo:

1. Abre Disk Usage y revisa el gráfico de barras.
2. Baja al listado por directorios; pulsa para expandir rutas y ver subcarpetas.
3. Identifica “sospechosos habituales”: mail/, public_html/wp-content/uploads, cachés, tmp, logs.
4. Usa File Manager para entrar al directorio pesado y ordenar por tamaño.
5. Decide: ¿limpio, archivo o muevo?
   • Limpio: caches de plugins, temporales, copias locales innecesarias.
   • Archivo: sube a almacenamiento externo adjuntos antiguos o zips.
   • Muevo: backups a un bucket S3 o a otra máquina.

Cuando mi web “iba rara” y la CPU se veía bien, abrir Disk Usage me enseñó un mail/ con años de adjuntos acumulados. Fue limpiar y la web dejó de “ahogarse” en I/O. Lección: el correo es el elefante invisible en muchos hostings compartidos.

Tips prácticos en cPanel:

• Activa y revisa cuotas por cuenta si el proveedor lo permite.
• No borres logs a ciegas: mejor comprimir y rotar.
• Si el problema son inodes, busca carpetas con miles de archivos pequeños (caches, sesiones, miniaturas).

WHM (admin cPanel): Salud del sistema → Mostrar uso de disco actual (interpretar Device/Size/Used/Available/%/Mount Point)

A nivel administrador (WHM), me voy a System Health → Show Current Disk Usage. Aquí ves todas las particiones y su % de uso con su mount point. Mi lectura:

• Percent Used: por encima del 85–90 % empiezo a actuar.
• Mount Point: si /var va justo, pienso en logs, mail y bases de datos; si /home, sospecho uploads, backups y cuentas ruidosas.
• Size vs. Used: ¿tiene sentido el crecimiento respecto al histórico? Si el salto es brusco, reviso eventos (deploys, backup fallido, import masivo).

Con WHM también reviso:

• List Accounts para detectar cuentas grandes y Quota Modification si toca ajustar.
• Log File Rotation para asegurar que no estoy guardando historia infinita.
• Backup Configuration para evitar retener N copias locales pesadas.

Un truco que me ha salvado: antes de ampliar disco, mover backups fuera y reconfigurar retención. Muchas veces es suficiente para volver a un rango sano sin tocar hardware.

Plesk (usuario y admin): rutas rápidas para ver uso por suscripción y dominio (equivalentes a Disk Usage)

En Plesk, el camino suele ser: Suscripciones → [tu suscripción] → Estadísticas. Ahí encuentras el Uso de disco desglosado por Web, Correo, Bases de datos, Logs y Backups. Me gusta porque te muestra dónde se está yendo el espacio sin tener que peinar árbol por árbol.

Flujo rápido que suelo usar:

1. Suscripciones → Estadísticas: miro el total y el reparto por categorías.
2. Correo: si es alto, entro a Direcciones de email y reviso buzones grandes.
3. Bases de datos: desde Bases de datos veo tamaños por instancia; si hay tablas de sesiones gigantes, programo una purga.
4. Archivos: Administrador de archivos para ordenar por tamaño y localizar zip/backup olvidados.
5. Herramientas y configuración (admin): ajustes de backup y rotación de logs.

En mi caso, Plesk me ha enseñado más de una vez que el problema no estaba en la web sino en Logs o Backups de la suscripción. Con dos clics ajustas la retención y recuperas varios GB. Si el cuello es Correo, Plesk facilita políticas por buzón y límites por plan.

Buenas prácticas en Plesk:

• Activa notificaciones de cuota para avisar al cliente antes de llegar al límite.
• Define retención de backups conservadora y destino remoto (S3/FTP).
• Si usas extensiones de caché, confirma su limpieza programada.

DirectAdmin: Resumen del sitio / Estadísticas / Logs y Estadísticas de dominio (qué mirar y por qué)

En DirectAdmin, desde Usuario tienes dos paradas claras:

1. Site Summary / Statistics / Logs (Resumen / Estadísticas / Logs)
   • Vista rápida de espacio en disco y ancho de banda.
   • Ideal para comprobar si el pico es global o de un dominio.
2. Account Manager → Disk Usage o Estadísticas de dominio
   • Desglose por directorios y elementos (web, correo, bases de datos) para cada dominio.
   • Útil para detectar si el problema viene de domains/tu-dominio/public_html/, imap/ (correo) o backups locales.

Mi experiencia aquí: DirectAdmin suele “cantar” muy rápido cuando Maildir se desmadra. En una ocasión, la gráfica se disparaba pero la web estaba ligera; la causa era un buzón de soporte con adjuntos monstruosos. Solución: archivar fuera y establecer límites por buzón.

Tips DirectAdmin:

• Revisa Inode Usage si el proveedor lo habilita; es una métrica que pasa desapercibida.
• Verifica cuotas por usuario/dominio para evitar sorpresas.
• Los logs de dominio también crecen: programa rotación y compresión.

Si el disco ya está al 90 %: acciones seguras para liberar espacio sin romper producción

Cuando veo un 90 % o más, actúo con bisturí:

1. Congela el crecimiento
   • Pausa tareas ruidosas (backups locales, cronjobs de import masivo, rotaciones de imágenes).
   • Si hay binlogs o logs que crecen por un bug, corrige la causa antes de borrar.
2. Gana oxígeno rápido (bajo riesgo)
   • Comprime o rota logs antiguos.
   • Limpia cachés y tmp (confirmando que no afectas sesiones activas).
   • Mueve backups a remoto y elimina duplicados locales.
3. Cirugía intermedia
   • Revisa Maildir y archiva adjuntos viejos.
   • Depura tablas de sesiones y limpia archivos órfanos en uploads (miniaturas obsoletas).
4. Cambio estructural (si procede)
   • Ajusta retenciones de backups y logs.
   • Reubica rutas pesadas a particiones separadas (si tienes margen).
   • Planifica ampliación si el crecimiento es legítimo (no basura).

A mí me ha salvado muchas veces un plan escalonado: primero oxígeno, luego limpieza con cabeza y por último prevención para que no vuelva.

---

Rutina mensual (la que me funciona): comandos, alertas y limpieza preventiva

Mi revisión periódica combina panel + CLI. Estos son mis imprescindibles:

Visión global

df -h             # Particiones y % uso en formato legible
df -i             # Inodes usados por partición

Radiografía por carpeta (en el punto caliente)

cd /ruta/sospechosa
du -sh * | sort -h     # Top por tamaño
# Opcional (interactivo y rapidísimo)
ncdu /ruta/sospechosa  # Navega y borra con seguridad

Logs con systemd

journalctl --disk-usage
sudo journalctl --vacuum-time=14d   # Conserva 14 días

Binlogs de MySQL/MariaDB (con cuidado)

# Tras verificar backups y réplica:
PURGE BINARY LOGS BEFORE DATE(NOW()) - INTERVAL 7 DAY;

Script mínimo de alerta por % de disco

#!/usr/bin/env bash
THRESHOLD=85
ALERT_TO="admin@example.com"

while read -r line; do
  USEP=$(echo "$line" | awk '{print $5}' | tr -d '%')
  PART=$(echo "$line" | awk '{print $6}')
  if [ "$USEP" -ge "$THRESHOLD" ]; then
    printf "Alerta: %s al %s%% de uso\n" "$PART" "$USEP" | mail -s "Alerta de disco" "$ALERT_TO"
  fi
done < <(df -hP | awk 'NR>1 {print $0}')

Programa este script con cron (diario) y ajusta THRESHOLD a tu gusto. Prefiero recibir un aviso al 80–85 % y actuar con margen.

Políticas que me han evitado sustos:

• Retención finita de backups/logs (y compresión).
• Caches con TTL real (no “infinito”).
• Límites de buzón y educación a usuarios (“archivar adjuntos fuera”).
• Auditoría trimestral de proyectos “zombies” que aún ocupan espacio.

---

Errores típicos que he visto (y cómo evitarlos la próxima vez)

• Depender de backups locales “temporales” que se quedan para siempre. Solución: destino remoto por defecto y retención estricta.
• Rotación de logs inexistente o mal configurada. Solución: revisa logrotate y niveles de logging.
• Confiar solo en la CPU/RAM para medir salud. Solución: añade disco e inodes a tus dashboards.
• Borrar a ciegas sin entender la causa del crecimiento. Solución: diagnostica primero, automatiza después.
• Ignorar inodes: el disco “parece libre” en GB pero el sistema se queda sin archivos disponibles. Solución: monitoriza df -i y controla caches con millones de ficheros.

Más de una vez me he encontrado con un /var/log de decenas de GB por un nivel de depuración olvidado tras un incidente. Desde entonces, después de cada “apagafuegos”, vuelvo a poner el nivel normal y cierro la puerta a ese crecimiento silencioso.

---

Preguntas frecuentes

¿GB vs. inodes: en qué me fijo?
En ambos. GB te dice “cuánto” pesa; inodes te dice “cuántos** archivos hay. Puedes tener 20 % de GB libres y aun así “sin espacio” por falta de inodes. Revisa df -i.

¿Qué umbral considero crítico?
Yo actúo al 80–85 %. Por encima del 90 % entro en modo “oxígeno rápido” y estabilizo antes de hacer cambios mayores.

¿Qué carpetas suelen dispararse sin que lo notes?
/var/log, mail/, caches de aplicaciones, tmp, backups locales, uploads con miniaturas.

¿Qué hago si no puedo borrar nada “ya”?
Mueve temporalmente backups a remoto, comprime logs históricos, limpia caches seguras y gana margen. Luego investiga y corrige la raíz.

---

Sobre revisar espacio en disco

Revisar el espacio en disco no es una tarea de “cuando me acuerde”, es una rutina de salud que evita sustos caros. Con las vistas de cPanel, WHM, Plesk y DirectAdmin (más una pasadita por CLI con df, du y ncdu) consigues una radiografía clara: qué crece, dónde y por qué. En mi experiencia, mirar esto de forma periódica da una tranquilidad enorme: sabes en qué estado estás y hacia dónde creces, tomas decisiones con tiempo y evitas que todo se rompa el día menos oportuno.

Opinión Personal

Revisar el espacio en disco no es glamuroso, pero es lo que separa a un servidor fiable de un incendio a medianoche. He visto webs “perfectas” caerse por un /var/log desbocado, migraciones fallar por binlogs eternos y equipos culpar a la RAM cuando el verdadero culpable era un mail/ con años de adjuntos. Para mí, cPanel, Plesk y DirectAdmin son solo puertas de entrada a la misma verdad: si no mides, no controlas; si no controlas, pagas el precio en el peor momento.

Mi postura es simple: trata el disco como tratas la seguridad. Reglas, rutina y alertas. En cPanel miro Disk Usage antes de tocar nada; en Plesk reviso Estadísticas por suscripción como quien consulta el extracto bancario; en DirectAdmin, las Estadísticas de dominio son mi semáforo: si amarillea, actúo antes del rojo. ¿La clave? Convertir la “limpieza” en hábito: rotación de logs, backups fuera del servidor, TTL real en cachés y un cron que avise cuando pasas del 80–85 %. Es aburrido… hasta que te ahorra horas de pánico y reputación.

También creo que hay que perderle el miedo a borrar lo correcto: comprime históricos, archiva adjuntos antiguos, elimina zips olvidados. La optimización no es “hacer magia”, es quitar polvo donde nadie mira. Y sí, medir inodes debería ser tan normal como ver el uso en GB: las caídas por millones de ficheritos son más comunes de lo que creemos.

Ahora te leo: ¿qué panel usas y cuál ha sido tu mayor “susto” de disco? ¿Tienes algún truco infalible para liberar espacio sin romper nada? Déjame tus comentarios abajo y enriquezcamos la guía entre todos.