Cómo ver el almacenamiento en Ubuntu Server: Una guía definitiva para gestionar tu espacio en disco

Imaginemos por un momento a Juan, un administrador de sistemas experimentado, en medio de la noche. De repente, su teléfono suena con una alerta crítica: «¡Espacio en disco bajo en el servidor de producción!». Un escalofrío le recorre la espalda. Sabe que una situación así puede derivar rápidamente en un caos: bases de datos que no escriben, aplicaciones que fallan, y el temido mensaje de «servicio no disponible» para los usuarios. Para Juan, y para cualquier profesional que trabaje con servidores, saber cómo ver el almacenamiento en Ubuntu Server no es solo una habilidad útil, es una necesidad imperativa, una cuestión de supervivencia operativa.

La gestión del espacio en disco es uno de esos pilares fundamentales que, si se descuidan, pueden desestabilizar incluso la infraestructura más robusta. Entender dónde se guarda la información, cuánto espacio queda y qué está consumiendo ese valioso recurso es crucial para mantener la salud y el rendimiento de nuestros sistemas. Afortunadamente, Ubuntu Server, como buen sistema operativo Linux, nos ofrece una panoplia de herramientas potentes y flexibles para esta tarea. Aquí, desglosaremos a fondo cada una de ellas, desde las más sencillas hasta las más especializadas, para que nunca más te encuentres a ciegas frente al misterio del espacio en disco.

Para responder directamente a la pregunta que nos trae aquí: la forma más rápida y común de verificar el almacenamiento en Ubuntu Server es a través de los comandos `df -h` y `du -sh`. Pero, ¿son estos suficientes? ¡Claro que no! Son solo la punta del iceberg. Prepárate para zambullirte en el fascinante mundo de la inspección del almacenamiento, donde la profundidad de tu conocimiento te permitirá no solo reaccionar a los problemas, sino anticiparte a ellos.

Los Fundamentales: Comandos Básicos para Ver el Espacio en Disco

Comencemos por el principio, por esas herramientas que todo administrador de sistemas en Ubuntu Server debería tener grabadas a fuego en la memoria. Son nuestros primeros aliados para obtener una visión general y para empezar a localizar posibles problemas.

df: Un Vistazo General al Uso del Sistema de Archivos

El comando `df`, que significa «disk free», es probablemente el más utilizado para obtener un resumen rápido del espacio en disco de los sistemas de archivos montados. Su función principal es mostrar la cantidad de espacio disponible y utilizado en todos los dispositivos de almacenamiento que están actualmente accesibles por el sistema operativo. Es una herramienta esencial para un primer diagnóstico.

Cuando ejecutas `df` sin ninguna opción, te devuelve información en bloques de 1KB, lo cual puede ser un poco difícil de leer. Por ello, la opción más común y, diría yo, casi obligatoria, es `-h` (human-readable).

df -h

Este comando te mostrará una tabla con varias columnas:

• Sistema de archivos: El nombre del dispositivo o sistema de archivos (ej., `/dev/sda1`, `tmpfs`).
• Tamaño: El tamaño total del sistema de archivos.
• Usado: El espacio ocupado.
• Disp.: El espacio disponible.
• Uso%: El porcentaje de espacio usado.
• Montado en: El punto de montaje donde el sistema de archivos está accesible.

Además de `-h`, hay otras opciones increíblemente útiles:

• `-T` (type): Muestra el tipo de sistema de archivos (ext4, XFS, tmpfs, etc.). Esto puede ser muy valioso para entender la configuración de tu almacenamiento.
• `-i` (inodes): En lugar de bloques de disco, muestra el uso de inodos. A veces, puedes tener mucho espacio en disco disponible, pero quedarte sin inodos (estructuras de datos que describen los archivos), lo que impide crear nuevos archivos.
• `-x TIPO_FS`: Excluye sistemas de archivos de un tipo específico. Por ejemplo, `df -h -x tmpfs` te ayudaría a ignorar los sistemas de archivos temporales en RAM, que a menudo son ruidosos en la salida.
• `-a` (all): Incluye sistemas de archivos con 0 bloques, que normalmente se omiten.

Un ejemplo típico de la salida de `df -hT` podría ser:

Sistema de archivos   Tipo     Tamaño Usado  Disp. Uso% Montado en
/dev/sda1             ext4      20G  8.5G   10G  46% /
tmpfs                 tmpfs    1.9G     0  1.9G   0% /dev/shm
/dev/sdb1             ext4      50G   30G   18G  63% /var/www

Interpretar esta salida es clave. Si ves un porcentaje de uso muy alto (por encima del 80-90%) en particiones críticas como `/` (la raíz) o `/var`, es una señal de alarma que requiere una investigación más profunda. ¡Ahí es donde entra en juego nuestra siguiente herramienta!

du: Escarbando en el Consumo de Directorios

Mientras `df` nos da una panorámica general de los sistemas de archivos, `du` (disk usage) es el comando para, como diríamos coloquialmente, «meterle el ojo» a dónde se está yendo el espacio dentro de un directorio específico. Si `df` te dice que tu partición `/var` está al 90%, `du` te ayudará a encontrar qué subdirectorio o archivo dentro de `/var` es el culpable.

El uso más común de `du` es para resumir el tamaño de un directorio y sus subdirectorios. Al igual que `df`, la opción `-h` (human-readable) es casi indispensable para hacer la salida comprensible.

du -h /var

Este comando recorrerá todo el directorio `/var` y sus subdirectorios, mostrando el tamaño de cada uno de ellos, lo cual puede generar una salida muy extensa. Para obtener un resumen del tamaño total de un directorio sin listar todos los subdirectorios, usamos la opción `-s` (summarize):

du -sh /var

Esto nos daría una línea como:

30G     /var

Si la salida de `df` te dijo que `/var` usaba 30GB, y `du -sh /var` te confirma esos 30GB, el siguiente paso es identificar qué subdirectorio dentro de `/var` es el más grande. Aquí es donde combinamos `du` con otras herramientas:

du -h --max-depth=1 /var | sort -rh

Vamos a desglosar este comando:

• `du -h`: Muestra el uso de disco de los directorios de forma legible.
• `–max-depth=1`: Limita la profundidad de la búsqueda a solo un nivel dentro de `/var`. Esto evita una salida abrumadora y te muestra los subdirectorios directamente dentro de `/var`.
• `| sort -rh`: La tubería (`|`) envía la salida de `du` al comando `sort`. La opción `-r` ordena en orden inverso (del más grande al más pequeño) y `-h` hace que `sort` entienda los tamaños legibles por humanos (ej., 1.5G, 20M), lo cual es crucial para que la ordenación sea correcta.

La salida de esto podría ser algo como:

20G     /var/log
5.0G    /var/www
3.0G    /var/lib
1.0G    /var/cache

¡Eureka! Ahora sabemos que los logs en `/var/log` son los que más espacio están consumiendo. Con esta información, podemos empezar a investigar por qué son tan grandes y cómo gestionarlos.

Otras opciones útiles para `du` incluyen:

• `-c` (total): Muestra un total general al final de la salida.
• `-a` (all): Incluye archivos además de directorios.
• `–exclude=PATRÓN`: Excluye archivos o directorios que coincidan con un patrón. Por ejemplo, para ignorar un directorio de caché.

Es importante recordar una distinción fundamental: `df` muestra el espacio que el sistema de archivos ve como «usado», que incluye bloques reservados para el sistema, archivos borrados que aún están siendo abiertos por un proceso, y el tamaño del sistema de archivos en general. `du`, en cambio, suma el tamaño de los archivos y directorios reales. Por ello, es común que haya una pequeña, o a veces grande, discrepancia entre los valores de `df` y `du` para el mismo punto de montaje. ¡Esto es normal y lo explicaremos en detalle en las preguntas frecuentes!

Más Allá de lo Básico: Profundizando en la Gestión del Almacenamiento

Una vez que dominamos `df` y `du`, es hora de subir de nivel. El almacenamiento en un servidor moderno puede ser mucho más complejo que una simple partición. Podemos encontrar LVM, arreglos RAID, y varios dispositivos de bloque. Para entender y gestionar estas configuraciones, necesitamos herramientas más específicas.

lsblk: Listando Dispositivos de Bloque

El comando `lsblk` (list block devices) es una joya para ver los dispositivos de almacenamiento disponibles en tu sistema, cómo están particionados y dónde están montados. A diferencia de `df` que muestra los sistemas de archivos montados, `lsblk` muestra la estructura jerárquica de los dispositivos de bloque, incluyendo discos duros, particiones y volúmenes lógicos, incluso si no están montados.

lsblk

La salida por defecto es bastante clara:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0    50G  0 disk 
├─sda1        8:1    0     1G  0 part /boot
└─sda2        8:2    0    49G  0 part 
  ├─ubuntu--vg-ubuntu--lv 253:0    0    40G  0 lvm  /
  └─ubuntu--vg-swap--lv 253:1    0     4G  0 lvm  [SWAP]
sdb           8:16   0   100G  0 disk 
└─sdb1        8:17   0   100G  0 part /var/www

Esta vista jerárquica es fantástica porque te muestra claramente cómo un disco físico (`sda`) se divide en particiones (`sda1`, `sda2`) y cómo esas particiones pueden formar parte de un Volúmen Lógico (`lvm`).

Opciones muy útiles para `lsblk` son:

• `-f` (filesystem): Muestra información del sistema de archivos (etiqueta, UUID, tipo de FS) para cada dispositivo.
• `-m` (permissions): Muestra información de permisos y propietario de los dispositivos.
• `-o LISTA_COLUMNAS`: Permite especificar qué columnas quieres ver. Por ejemplo, `lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT` te da una salida más específica.

lsblk -f

NAME        FSTYPE LABEL UUID                                 MOUNTPOINTS
sda                                                              
├─sda1      ext4   boot  2d0c2e30-b46f-4d6d-9e6e-0a5d4a1b2c3d /boot
└─sda2      LVM2_m vgroup b0d1d7e2-1a2b-4c3d-9e0f-1a2b3c4d5e6f 
  ├─ubuntu--vg-ubuntu--lv
  │         ext4         a1b2c3d4-e5f6-7890-1234-567890abcdef /
  └─ubuntu--vg-swap--lv
            swap         fedcba98-7654-3210-fedc-ba9876543210 [SWAP]
sdb                                                              
└─sdb1      ext4   data  6e7f8g9h-0i1j-2k3l-4m5n-6o7p8q9r0s1t /var/www

Con `lsblk`, puedes discernir rápidamente si estás trabajando con un disco completo, una partición, un volumen lógico o incluso un dispositivo de red mapeado. Es la brújula para navegar por la topología física y lógica de tu almacenamiento.

fdisk y parted: Detallando Particiones

Cuando necesitas ir aún más allá en los detalles de las tablas de particiones, `fdisk` y `parted` son las herramientas a las que recurrir. `fdisk` es el clásico para sistemas con tabla de particiones MBR (Master Boot Record), mientras que `parted` es más moderno y soporta MBR y GPT (GUID Partition Table), siendo este último el estándar para discos grandes y sistemas UEFI.

Para ver las particiones de un disco específico con `fdisk` (normalmente necesitas privilegios de root):

sudo fdisk -l /dev/sda

La opción `-l` lista las particiones del dispositivo indicado. La salida te mostrará información sobre el tipo de tabla de particiones, la geometría del disco, y una lista detallada de cada partición, incluyendo su número, inicio, fin, tamaño y tipo. Esto es fundamental para entender cómo está dividido el disco físico.

Disco /dev/sda: 50 GiB, 53687091200 bytes, 104857600 sectores
Unidades: sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico/físico): 512 bytes / 512 bytes
Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes
Tipo de etiqueta de disco: dos
Identificador de disco: 0x12345678

Dispositivo  Inicio       Fin     Sectores  Tamaño Tipo
/dev/sda1      2048   2099199    2097152      1G Linux
/dev/sda2   2099200 104857599  102758400     49G Linux LVM

Con `parted`, el enfoque es similar, pero su interactividad es diferente. Para ver las particiones de un disco:

sudo parted /dev/sda print

Esto te dará una salida similar a `fdisk -l`, pero con más detalles sobre el tipo de tabla de particiones (ej., `msdos` para MBR, `gpt` para GPT) y alineación. `parted` es especialmente útil cuando necesitas información sobre discos de gran tamaño o cuando se requiere la flexibilidad de GPT.

Modelo: Virtio Block Device (virtblk)
Disco /dev/sda: 53.7GB
Tamaño de sector (lógico/físico): 512B/512B
Tabla de particiones: gpt
Banderas de disco: 

Número  Inicio  Fin     Tamaño  Sistema de archivos  Nombre  Banderas
 1      1049kB  1075MB  1074MB  ext4                         arranque
 2      1075MB  53.7GB  52.6GB                               lvm

Estas herramientas son más para una inspección profunda de la estructura de tus discos, ideal cuando se está depurando problemas de montaje, reconfigurando el almacenamiento o verificando la correcta inicialización de nuevos discos.

LVM (Logical Volume Management): Cuando las Particiones Son Flexibles

En entornos de servidor, es muy común encontrar LVM (Logical Volume Management). LVM es una capa de abstracción sobre las particiones físicas que permite una gestión del almacenamiento mucho más flexible. En lugar de estar atados al tamaño y ubicación de las particiones físicas, LVM nos permite crear «volúmenes lógicos» que pueden extenderse sobre múltiples discos o particiones, y que pueden redimensionarse, moverse y crearse con facilidad mientras el sistema está en línea.

Si tu Ubuntu Server utiliza LVM, necesitarás comandos específicos para ver su configuración de almacenamiento:

• `pvs` (physical volumes): Muestra los volúmenes físicos (particiones o discos completos) que están siendo usados por LVM. Te dirá qué discos o particiones (`/dev/sda2` en el ejemplo de `lsblk`) son parte de un grupo de volúmenes LVM.
• `vgs` (volume groups): Muestra los grupos de volúmenes. Un grupo de volúmenes es una colección de volúmenes físicos, y es desde donde se asigna el espacio para los volúmenes lógicos.
• `lvs` (logical volumes): Muestra los volúmenes lógicos. Estos son los «discos» que el sistema operativo ve y utiliza, y que se montan como sistemas de archivos.

Veamos un ejemplo de sus salidas:

sudo pvs

  PV         VG        Fmt  Attr PSize   PFree
  /dev/sda2  ubuntu-vg lvm2 a--  <49.00g    0
  /dev/sdc1  data-vg   lvm2 a--  <100.00g    0

sudo vgs

  VG        #PV #LV #SN Attr   VSize    VFree
  data-vg     1   1   0 wz--n- <100.00g    0 
  ubuntu-vg   1   2   0 wz--n- <49.00g    0 

sudo lvs

  LV        VG        Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data-lv   data-vg   -wi-ao---- <100.00g                                                    
  ubuntu-lv ubuntu-vg -wi-ao----  <40.00g                                                    
  swap-lv   ubuntu-vg -wi-ao----   4.00g                                                    

Al combinar la información de `lsblk` con `pvs`, `vgs` y `lvs`, puedes construir una imagen completa de cómo está configurado tu almacenamiento físico y lógico, lo cual es invaluable para la planificación de capacidad y la resolución de problemas en entornos LVM.

RAID (Redundant Array of Independent Disks): Visibilidad en Arreglos de Discos

En muchos servidores, especialmente aquellos que requieren alta disponibilidad y redundancia de datos, se utilizan arreglos RAID. RAID combina múltiples discos físicos en una sola unidad lógica para mejorar el rendimiento, la redundancia o ambas cosas. En Linux, a menudo se implementa con "software RAID" utilizando el controlador `md` (multiple device).

Para verificar el estado y la configuración de un arreglo RAID en tu Ubuntu Server, hay dos fuentes principales de información:

1. `/proc/mdstat`: Este archivo pseudo-sistema de archivos proporciona un resumen rápido del estado de los arreglos RAID activos. Puedes verlo con `cat`.
2. `mdadm --detail`: Este comando ofrece una información mucho más detallada sobre un arreglo RAID específico.

cat /proc/mdstat

Personalities : [raid1] [raid6] [raid5] [raid4] [raid0] [raid10]
md127 : active raid1 sdb1[0] sda1[1]
      10485632 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

En esta salida, vemos que hay un arreglo `md127` de tipo RAID1, compuesto por `sdb1` y `sda1`. `[2/2] [UU]` significa que hay dos discos en el arreglo y ambos están "Up" (funcionando correctamente). Si vieras `[_U]` o `[U_]`, indicaría que un disco ha fallado.

Para obtener un nivel de detalle mucho mayor sobre un arreglo específico (por ejemplo, `/dev/md127`):

sudo mdadm --detail /dev/md127

/dev/md127:
        Version : 1.2
  Creation Time : Mon Jan 1 00:00:00 2023
     Raid Level : raid1
     Array Size : 10485632 (10.00 GiB 10.74 GB)
  Used Dev Size : 10485632 (10.00 GiB 10.74 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Tue Jun 20 10:30:00 2023
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : ubuntu-server:127  (local to host ubuntu-server)
           UUID : a1b2c3d4:e5f6g7h8:i9j0k1l2:m3n4o5p6

    Devices :
       ID     State       Events   Device
       0      active      sync   /dev/sdb1
       1      active      sync   /dev/sda1

Este comando te brinda información crítica como el nivel de RAID, el tamaño del arreglo, el estado general (`clean` es bueno), y la lista de los dispositivos individuales con su estado. Esto es vital para el monitoreo de la salud del almacenamiento en arreglos RAID.

Herramientas Avanzadas y Consejos Prácticos para el Monitoreo

Saber los comandos básicos es solo el primer paso. Un verdadero "maestro del almacenamiento" utiliza una combinación de herramientas para obtener una visión completa y, lo que es más importante, para diagnosticar problemas complejos. Aquí exploramos algunas de esas herramientas y técnicas.

ncdu: Una Interfaz Interactiva para Explorar el Espacio

Si alguna vez te has sentido abrumado por la salida de `du` con muchas carpetas y subcarpetas, `ncdu` (NCurses Disk Usage) es tu salvación. Es una utilidad basada en terminal que ofrece una interfaz interactiva y gráfica (aunque de texto) para explorar el uso del disco. Es como un `du` visual, pero en tu terminal SSH.

Primero, podrías necesitar instalarlo:

sudo apt update
sudo apt install ncdu

Luego, simplemente ejecútalo en el directorio que quieres analizar (por ejemplo, la raíz `/` o `/var`):

ncdu /

`ncdu` escaneará el directorio (lo cual puede tomar un tiempo en sistemas grandes) y luego presentará una lista de directorios ordenados por tamaño, junto con una barra gráfica de su consumo. Puedes navegar por los directorios usando las teclas de flecha, entrar en ellos con "Enter" y volver atrás con "q". También te permite borrar archivos y directorios directamente desde la interfaz, si tienes los permisos necesarios. Es, sin duda, una de las herramientas más eficientes para encontrar rápidamente dónde se ha "escondido" el espacio en disco.

lsof: Identificando Archivos Abiertos

A veces, te encuentras con una situación desconcertante: `df` muestra que una partición está casi llena, pero cuando usas `du` para sumar el tamaño de todos los archivos y directorios, la suma es significativamente menor que el espacio reportado como usado por `df`. Este es el clásico "misterio del espacio fantasma", y a menudo la culpa la tienen los archivos que han sido eliminados pero que aún están abiertos por algún proceso.

Cuando un archivo se elimina, su entrada del directorio desaparece, pero el espacio en disco que ocupa no se libera hasta que ningún proceso lo tiene abierto. Si un proceso sigue escribiendo en él, o simplemente lo tiene abierto, ese espacio permanece "ocupado" aunque el archivo sea invisible para `ls` o `du`.

Aquí es donde `lsof` (list open files) brilla con luz propia. Con `lsof`, puedes listar todos los archivos abiertos por los procesos en tu sistema. Para encontrar archivos eliminados que aún están abiertos, puedes usar:

sudo lsof | grep deleted

Esto te mostrará una lista de archivos que tienen la etiqueta "(deleted)" en su nombre. La salida típica incluirá el PID del proceso que lo tiene abierto, el nombre del comando, y el nombre del archivo (originalmente, antes de ser borrado). Por ejemplo:

COMMAND     PID   USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
apache2   12345 www-data   10w   REG  253,0  1048576 123456 /var/log/apache2/access.log (deleted)

En este caso, un proceso `apache2` tiene abierto un archivo de log que ya fue eliminado. Para liberar ese espacio, tendrías que reiniciar el servicio `apache2` (o el proceso en cuestión) para que libere el manejador del archivo. Es una herramienta indispensable para resolver esos enigmas de espacio en disco que no cuadran.

Montajes Remotos y Almacenamiento en Red (NFS, Samba/CIFS)

Los servidores Ubuntu a menudo se conectan a almacenamiento en red, como recursos compartidos NFS (Network File System) o Samba/CIFS. Es importante recordar que `df` también reportará el uso de estos sistemas de archivos montados remotamente.

df -h

Podrías ver líneas como:

Sistema de archivos   Tipo     Tamaño Usado  Disp. Uso% Montado en
192.168.1.10:/data    nfs4     500G  300G  180G  63% /mnt/nfs_data

Esto te da una visibilidad instantánea del espacio disponible en tus recursos de almacenamiento en red, lo cual es tan crítico como el espacio en disco local. Al monitorear estos montajes, puedes anticipar problemas de capacidad en tu infraestructura de almacenamiento compartida y asegurarte de que tus aplicaciones tengan suficiente espacio para operar.

Monitoreo Continuo y Alertas

Mientras que los comandos que hemos visto son fantásticos para una verificación puntual o para la resolución de problemas, la gestión proactiva del almacenamiento en un entorno de servidor exige un monitoreo continuo. Dejarlo todo a verificaciones manuales es una receta para el desastre.

Es aquí donde entran en juego las herramientas de monitoreo de infraestructura. Sistemas como Nagios, Zabbix o Prometheus, junto con agentes de monitoreo, pueden recolectar métricas del uso del disco (`df` y `du` son la base) de forma regular y activar alertas automáticas (correos electrónicos, mensajes a Slack, etc.) cuando el uso del disco alcanza ciertos umbrales críticos. Implementar un sistema de monitoreo robusto es la mejor defensa contra las sorpresas desagradables de un disco lleno.

Casos Prácticos y Solución de Problemas Comunes

Ahora que conocemos las herramientas, es momento de ponerlas en práctica y abordar algunos de los escenarios más comunes que te encontrarás al gestionar el almacenamiento en Ubuntu Server.

¿Dónde se fue mi espacio en disco? Un Misterio Común

Este es el clásico. Recibes una alerta de disco bajo o, peor aún, tus servicios empiezan a fallar. Ejecutas `df -h` y ves que la partición `/var` está al 95%. ¡Auxilio! Pero, ¿qué está consumiendo tanto?

Pasos para diagnosticar:

1. Verifica los logs: La mayoría de los logs del sistema y de las aplicaciones se encuentran en `/var/log`. Ejecuta `sudo du -sh /var/log` para ver su tamaño total. Si es grande, profundiza con `sudo du -h --max-depth=1 /var/log | sort -rh` para ver qué archivo o directorio dentro de `/var/log` es el más grande. A menudo, un log de una aplicación que está generando muchos errores puede crecer descontroladamente.
2. Caché de paquetes: Ubuntu almacena los paquetes descargados por `apt` en `/var/cache/apt/archives`. Con el tiempo, esto puede acumularse. Usa `sudo du -sh /var/cache/apt/archives` para verificar.
3. Archivos temporales: Aunque `tmpfs` es común para `/tmp` y `/dev/shm`, algunas aplicaciones pueden crear archivos temporales grandes en otras ubicaciones. Revisa `/tmp` o directorios temporales específicos de tus aplicaciones.
4. Snapshots de máquinas virtuales o bases de datos: Si estás ejecutando máquinas virtuales o bases de datos con funcionalidades de snapshot, estos pueden consumir grandes cantidades de espacio.
5. Archivos abiertos eliminados: Como ya mencionamos, si `df` y `du` no coinciden significativamente, investiga con `sudo lsof | grep deleted`.
6. Home de usuarios: En servidores con múltiples usuarios o FTP, los directorios personales de los usuarios pueden llenarse rápidamente. Revisa `/home`.
7. Contenido web o bases de datos: Si el servidor aloja sitios web o bases de datos, los directorios como `/var/www` o `/var/lib/mysql` (o postgresql) son candidatos principales a revisar con `du`.

Con estos pasos, casi siempre podrás acorralar al "devorador de espacio".

Liberando Espacio: Más Allá de la Eliminación Directa

Una vez que has identificado al culpable, ¿cómo liberas el espacio de forma segura? No se trata solo de un `rm -rf` indiscriminado.

Estrategias para liberar espacio:

• Limpiar caché de paquetes:
  • `sudo apt clean`: Elimina todos los archivos `.deb` de `/var/cache/apt/archives`.
  • `sudo apt autoremove`: Elimina paquetes que fueron instalados como dependencias y ya no son necesarios.
• Gestionar logs:
  • `logrotate`: Ubuntu ya utiliza `logrotate` para gestionar los logs del sistema. Asegúrate de que tus aplicaciones personalizadas también lo usen. Si un log está creciendo desproporcionadamente, verifica la configuración de `logrotate` para ese log en `/etc/logrotate.d/`.
  • Truncar logs (con precaución): Si un archivo de log es masivo y no puedes reiniciar el servicio que lo está usando (para que `logrotate` lo rote y vacíe), puedes truncarlo. Por ejemplo, `sudo truncate -s 0 /var/log/miaplicacion.log`. ¡Pero esto solo debe hacerse si sabes que no perderás información vital y solo como una medida de emergencia!
  • Borrar logs antiguos manualmente (con extrema precaución): Para archivos muy antiguos que sabes que no son necesarios, puedes borrarlos directamente, pero siempre verifica que no estén abiertos por ningún proceso con `lsof`.
• Archivos temporales: Reiniciar el servidor limpiará el `tmpfs`. Para limpiar `/tmp` o directorios temporales de aplicaciones, borra los archivos antiguos de forma segura, o configura `tmpwatch` (o un script cron) para hacerlo automáticamente.
• Snapshots: Si estás usando LVM snapshots o snapshots de VMs, elimina los antiguos o los que ya no necesitas. Cada snapshot consume espacio.
• Archivos de core dumps: Si alguna aplicación ha fallado y generado un "core dump", estos archivos pueden ser muy grandes. Búscalos (`find / -name "core" -type f`) y elimínalos si no los necesitas para depuración.

La clave es siempre identificar la causa raíz del consumo excesivo antes de actuar, y proceder con cautela para evitar la pérdida de datos o la interrupción de servicios.

Preguntas Frecuentes (FAQs)

A menudo, la gestión del almacenamiento plantea dudas que van más allá de la ejecución de un simple comando. Aquí abordamos algunas de las preguntas más comunes y sus respuestas detalladas.

¿Por qué el comando `df` y `du` muestran diferentes usos de espacio?

Esta es una de las preguntas más recurrentes y motivo de mucha confusión. La discrepancia entre el espacio reportado por `df` y `du` para el mismo sistema de archivos es bastante común y, generalmente, tiene explicaciones lógicas.

Una de las razones principales es el escenario de los archivos eliminados pero aún abiertos. Cuando un archivo se borra con `rm`, el sistema de archivos marca sus bloques como disponibles y lo elimina del directorio. Sin embargo, si un proceso aún tiene abierto ese archivo (por ejemplo, un servidor web escribiendo en un archivo de log que acaba de ser rotado y eliminado), el kernel no libera los bloques de disco hasta que el último proceso que lo usa lo cierra. `df` cuenta esos bloques como "usados" porque aún están asignados, mientras que `du` no los ve porque la entrada del directorio ya no existe. Para resolver esto, a menudo basta con reiniciar el servicio que tiene el archivo abierto o el sistema completo.

Otra causa son los bloques reservados para el superusuario (root). Por defecto, los sistemas de archivos `ext` (ext2, ext3, ext4) reservan un pequeño porcentaje (normalmente 5%) del espacio total del disco para el usuario `root`. Esto se hace para asegurar que el administrador siempre tenga algo de espacio disponible para operaciones críticas, incluso si el disco está aparentemente lleno, evitando así que el sistema se bloquee por completo. `df` incluye este espacio reservado en su cálculo de "usado" o "disponible" de una manera que puede hacer que el espacio real disponible para usuarios no-root parezca menor. `du`, por otro lado, solo suma el tamaño de los archivos a los que tiene acceso, sin considerar bloques reservados.

Finalmente, existen los enlaces duros (hard links). Si tienes varios enlaces duros al mismo archivo, `du` los contará como archivos separados y sumará su tamaño múltiples veces, lo que podría llevar a que `du` reporte más espacio usado del que `df` ve realmente en bloques físicos.

¿Cómo puedo saber qué proceso está usando un archivo específico que ocupa mucho espacio?

Cuando `du` te indica que un archivo específico es el culpable de un gran consumo de espacio, y sospechas que un proceso lo tiene abierto, puedes usar `lsof` para identificarlo. Este comando es increíblemente potente para rastrear la actividad del sistema de archivos.

Para encontrar qué proceso tiene abierto un archivo en particular, puedes ejecutar:

sudo lsof /ruta/al/archivo_grande.log

Esto te devolverá una línea similar a la siguiente:

COMMAND     PID   USER   FD   TYPE DEVICE SIZE/OFF      NODE NAME
aplicacion  7890   user   12w   REG    8,1 1073741824 1234567 /ruta/al/archivo_grande.log

En esta salida, `aplicacion` es el nombre del comando, `7890` es el ID del proceso (PID), y `user` es el usuario que lo ejecuta. Con el PID, puedes investigar más a fondo el proceso, ver sus parámetros con `ps -fp 7890`, o incluso terminarlo si es necesario (siempre con cautela) usando `kill 7890`. Esta información es vital para depurar problemas de aplicaciones que escriben archivos de gran tamaño sin control o que no los liberan correctamente.

¿Es seguro borrar archivos directamente del directorio `/var/log/`?

Borrar archivos directamente de `/var/log/` puede parecer una solución rápida para liberar espacio, pero es una práctica que debe abordarse con mucha precaución y, preferiblemente, evitarse a menos que sea una emergencia y sepas exactamente lo que estás haciendo.

La razón principal es que muchos servicios de sistema y aplicaciones están constantemente escribiendo en sus archivos de log. Si simplemente borras un archivo de log con `rm` mientras un proceso aún lo tiene abierto, el proceso seguirá escribiendo en un descriptor de archivo que ya no tiene una entrada en el sistema de archivos. Esto no liberará el espacio en disco inmediatamente (como vimos con `lsof`) y, peor aún, si el proceso no tiene un mecanismo de manejo de errores robusto, podría fallar o comportarse de manera errática. Además, la información del log se perdería, lo cual es perjudicial para la depuración y auditoría.

La forma correcta y segura de gestionar los logs es a través de `logrotate`. Esta utilidad está diseñada específicamente para rotar, comprimir y eliminar logs antiguos de forma segura, notificando a los servicios para que cierren el archivo de log actual y abran uno nuevo. Si un archivo de log está creciendo desproporcionadamente, lo primero es verificar y ajustar su configuración en `/etc/logrotate.d/`. Si la situación es crítica y necesitas liberar espacio inmediatamente sin reiniciar el servicio, una opción más segura que `rm` es truncar el archivo: `sudo truncate -s 0 /var/log/miaplicacion.log`. Esto vacía el contenido del archivo sin eliminarlo, y el proceso que lo tiene abierto simplemente seguirá escribiendo desde el principio, liberando así el espacio.

¿Qué es un inodo y por qué puedo quedarme sin inodos aunque tenga espacio en disco?

Un inodo (del inglés "index node") es una estructura de datos en los sistemas de archivos tipo Unix (como ext4) que almacena información sobre un archivo o directorio. Cada archivo, directorio, enlace simbólico o dispositivo especial en un sistema de archivos tiene exactamente un inodo. La información que un inodo almacena incluye el propietario del archivo, el grupo, los permisos, la fecha y hora de creación/modificación/acceso, y un puntero a los bloques de datos en el disco donde se encuentra el contenido real del archivo. Lo que NO almacena el inodo es el nombre del archivo o su ruta, esa información se guarda en las entradas del directorio.

Cada sistema de archivos tiene un número limitado de inodos preasignados cuando se crea. Si bien normalmente el número de inodos es más que suficiente para la mayoría de los casos, puedes quedarte sin inodos incluso si todavía tienes mucho espacio libre en disco. Esto ocurre cuando tienes una cantidad extremadamente grande de archivos muy pequeños. Piensa en millones de archivos de caché de pocos kilobytes, sesiones PHP, correos electrónicos individuales, o cualquier aplicación que genere un sinfín de archivos diminutos.

Cuando te quedas sin inodos, el sistema de archivos no puede crear nuevos archivos, incluso si hay gigabytes de espacio disponible. Recibirás errores como "No space left on device" o "Disk quota exceeded", que pueden ser engañosos. Para verificar el uso de inodos en tus sistemas de archivos, usa el comando `df` con la opción `-i`:

df -i

Si alguna de las particiones muestra un porcentaje de uso de inodos (IUse%) cercano al 100%, ¡has encontrado el problema! Para solucionarlo, deberás identificar los directorios con una gran cantidad de archivos pequeños (usando `find . -type f | wc -l` en los directorios sospechosos) y eliminar los que no sean necesarios, o considerar rediseñar cómo se almacenan esos datos.

¿Cómo puedo extender una partición o volumen lógico sin perder datos?

Extender el tamaño de una partición o volumen lógico es una tarea común en el mantenimiento de servidores, especialmente cuando el espacio se agota. La forma de hacerlo depende de si estás usando LVM o particiones tradicionales.

Si estás utilizando LVM (Logical Volume Management), extender un volumen lógico es relativamente sencillo y, lo más importante, se puede hacer sin perder datos y, a menudo, sin tiempo de inactividad (aunque un reinicio del servicio que usa el sistema de archivos puede ser necesario para que vea el nuevo tamaño). Los pasos generales son:

1. Añadir más espacio físico: Esto podría significar añadir un nuevo disco duro, añadir una nueva partición de un disco existente, o expandir una partición existente que forma parte de un Volumen Físico (PV) LVM.
2. Extender el Volumen Físico (PV): Si expandiste una partición existente que es un PV, necesitas decirle a LVM que escanee el nuevo tamaño con `sudo pvresize /dev/sdaX`.
3. Extender el Grupo de Volúmenes (VG): Si añadiste un nuevo disco o partición como un nuevo PV, debes añadirlo a tu Grupo de Volúmenes existente con `sudo vgextend nombre_del_vg /dev/sdYY`.
4. Extender el Volumen Lógico (LV): Ahora que el Grupo de Volúmenes tiene más espacio, puedes extender el Volumen Lógico específico con `sudo lvextend -L +XG /dev/nombre_del_vg/nombre_del_lv` (reemplazando `XG` con el tamaño adicional) o `sudo lvextend -l +100%FREE /dev/nombre_del_vg/nombre_del_lv` para usar todo el espacio libre disponible en el VG.
5. Redimensionar el Sistema de Archivos: Finalmente, necesitas decirle al sistema de archivos (ext4, XFS, etc.) que use el nuevo espacio. Para ext4, esto se hace con `sudo resize2fs /dev/nombre_del_vg/nombre_del_lv`. Para XFS, `sudo xfs_growfs /punto_de_montaje_del_lv`. Este paso es el que hace que el espacio adicional sea realmente utilizable.

Si estás usando particiones tradicionales (no LVM), extender una partición es más complicado y, a menudo, requiere tiempo de inactividad, ya que el sistema de archivos no puede estar montado mientras se manipula la tabla de particiones. Herramientas como `gparted` (para entorno gráfico) o `parted` (línea de comandos) pueden usarse, pero con un riesgo considerable de pérdida de datos si no se hace correctamente. La recomendación casi universal es hacer una copia de seguridad completa antes de intentar redimensionar particiones tradicionales.

Mi servidor Ubuntu se puso lento, ¿podría ser el almacenamiento?

¡Absolutamente! El rendimiento del almacenamiento es un factor crítico en la velocidad general de un servidor. Una baja velocidad de E/S (Input/Output) de disco puede ser un cuello de botella tan significativo como una CPU sobrecargada o poca RAM, y a menudo se manifiesta como una lentitud generalizada del sistema, incluso si la CPU y la memoria parecen estar bien.

Cuando un servidor se ralentiza, el almacenamiento podría ser el culpable por varias razones:

• Disco sobrecargado: Si el disco duro está constantemente ocupado con operaciones de lectura/escritura (E/S), cualquier otra aplicación que necesite acceder al disco se verá afectada, lo que lleva a la lentitud. Esto se puede deber a una aplicación que registra muchos datos, una base de datos con consultas ineficientes, o procesos de copia de seguridad intensivos.
• Espacio en disco bajo: Aunque el sistema no se bloquee por completo, un espacio en disco muy bajo (por debajo del 10-15% libre) puede degradar el rendimiento del sistema de archivos, ya que tiene que trabajar más para encontrar bloques contiguos libres para escribir.
• Fallos de disco o RAID: Un disco duro que está a punto de fallar o un arreglo RAID degradado (con uno o más discos fallidos) puede operar a velocidades significativamente más bajas, ya que el sistema de archivos o el controlador RAID tienen que lidiar con errores o reconstrucciones.
• Swapping excesivo: Si el servidor se queda sin RAM y empieza a usar intensamente el espacio de intercambio (swap) en el disco, esto puede ralentizar drásticamente el sistema, ya que el disco es exponencialmente más lento que la RAM.

Para investigar si el almacenamiento es el cuello de botella, puedes usar herramientas como `iostat` (del paquete `sysstat`). Ejecuta `iostat -x 1` para ver estadísticas detalladas de E/S cada segundo. Presta atención a la columna `%util`, que muestra el porcentaje de tiempo que el dispositivo está ocupado. Si esta métrica está consistentemente alta (por ejemplo, por encima del 70-80%) en tus discos principales, es una clara señal de un cuello de botella de E/S. También puedes usar `iotop` para ver qué procesos están generando más E/S de disco, de manera similar a cómo `top` muestra el uso de CPU y memoria.

Conclusión

Como hemos visto, la tarea de cómo ver el almacenamiento en Ubuntu Server va mucho más allá de ejecutar un simple comando. Es una habilidad multifacética que requiere el conocimiento de diversas herramientas y una comprensión profunda de cómo funciona el almacenamiento, desde el nivel de los dispositivos de bloque hasta la asignación de inodos y la gestión de volúmenes lógicos o arreglos RAID.

Dominar estas herramientas te convertirá en un administrador de sistemas mucho más eficaz y proactivo. Te permitirá no solo reaccionar ante las crisis de "disco lleno", sino, lo que es más importante, anticiparte a ellas mediante un monitoreo constante y una planificación adecuada de la capacidad. La proactividad en la gestión del almacenamiento es la mejor defensa contra la lentitud del sistema, la interrupción de servicios y los dolores de cabeza inesperados. Así que, la próxima vez que te enfrentes a un servidor Ubuntu, recuerda que tienes a tu disposición una completa caja de herramientas para mantener su almacenamiento bajo control.