El sistema de archivos raíz se está llenando, no hay archivos grandes

Soy un administrador de sistemas muy nuevo, acabo de salir de la escuela y hago mi pasantía. El único problema es que soy el único administrador de sistemas en el lugar y nadie para mostrarme el trabajo. De todos modos, es una empresa muy pequeña, un servidor CentOs con esa configuración:

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda3             184G  140G   35G  81% /

tmpfs                 2.3G     0  2.3G   0% /lib/init/rw

udev                  2.3G  212K  2.3G   1% /dev

tmpfs                 2.3G     0  2.3G   0% /dev/shm

/dev/sda1             4.6G  156M  4.2G   4% /boot

/dev/sda4              33G  176M   31G   1% /tmp

/dev/sdb1             1.8T  1.8T     0 100% /media/backupInterne

/dev/sdd1             917G  470G  401G  54% /media/Data

Llegué hace solo unos días, noté el disco completo de inmediato y estoy trabajando para solucionar ese problema. Mi otro problema aquí es sda3 ahora al 81%. Hace 4 días, estaba al 79%.

Corrí el du -ah | Comando sort -rh en el directorio / root, nada destaca. Lo hice con unos días de diferencia, ya que la partición sda3 se está llenando rápidamente, sin grandes diferencias que puedan explicar por qué está creciendo.

Muchas gracias

linux filesystems mount

— littleadmin
fuente

Supongo que sería un crecimiento logarítmico porque sdb1está lleno, pero veremos qué tan grande /vares ... ¿de qué obtienes du -sh /*?

— Shane Madden

Si desea ver qué archivos han cambiado, puede usar findcon -mtime n [smhdw]. Sospecho que Shane tiene razón. Parte de esto puede ser los archivos de registro quejándose del volumen sdb1 completo. El comando podría verse así: find / -type f -mtime 1d -print si su búsqueda es compatible, --exclude-dir=entonces es posible que desee excluir / dev y / proc.

— Hennes

/ var es 1.7G y su tamaño apenas se movió en los últimos días, fue mi primera idea comprobar eso. Siempre ejecuto el comando du con un --exclude = 'media' ya que no hay nada en ese directorio y luego

— monté

Desde que escribió que es un nuevo administrador, quisiera señalar una de las razones más comunes del uso creciente del disco. Archivos de registro. Si abre un archivo (por ejemplo, el registro de un servidor web) y luego lo elimina, el archivo seguirá utilizando espacio en disco hasta que el programa cierre su identificador a ese archivo. Esto último a veces se resuelve enviando un registro ( kill -1 PID-> releer el archivo de configuración y reiniciar para muchos demonios) o con el eje contundente de reiniciar.

— Hennes

En caso de que sea un crecimiento logarítmico, puede asentarse en unos pocos días cuando se inicie la rotación semanal del registro.

— ptman

Respuestas:

Esto es lo que uso al tratar de resolver problemas como este.

du -s `ls -a | egrep -v '\.\.'` | sort -nr | head

Le mostrará el uso por directorio / archivo en el directorio actual. Desde allí, baja a subdirectorios hasta que encuentre algo obvio.

Tener todo en una gran partición puede dificultar el diagnóstico de problemas como este. Otro enfoque para intentar es usar

lsof

para ver qué archivos están abiertos por los distintos procesos y ver si puedes encontrar algunas pistas. Sin embargo, esto es muy impredecible.

— Fred the Magic Wonder Dog
fuente

+1 por mencionar lsof. Esa herramienta será útil para un nuevo administrador (incluso si puede ser táctil e ir por este problema).

— Hennes

El uso por directorio / archivos me da 5 resultados, ninguno de ellos más de 600k.

— littleadmin

Suena mucho a un problema similar que tengo todo el tiempo con archivos eliminados (pero la referencia sigue ahí).

Si estamos hablando de un sistema Linux, ejecute:

lsof + L1

Esta será una lista de archivos eliminados, pero todavía están abiertos y están siendo utilizados por algo. La clave es obtener lo que tenga abierto el identificador de archivo para liberarlo.

— Eirik Toft
fuente

Lamentablemente, no proporcionó ningún archivo que pudiera explicar la pérdida de espacio que ocurre todos los días. gracias

— littleadmin

¿Es posible que algo esté escribiendo en un directorio que luego se está montando con un sistema de archivos? Tenía gigabytes de pelo inexplicable tirando sobre eso una vez. Si bien esto nunca debería ser posible, pude demostrar que puede suceder.

— Eirik Toft

Estoy pensando en algo así también, pero ¿cómo podría suceder eso? ¿Y cómo lo verifico sin desmontar todo?

— littleadmin

Finalmente descubrí lo que estaba pasando. Uno de los puntos montados no se montaba correctamente y, por lo tanto, estaba haciendo la copia de seguridad directamente en sda3.

Gracias a todos por la ayuda

— littleadmin
fuente