Como encontrar arquivos grandes no Linux

O alerta chega sempre no pior momento: No space left on device. O deploy trava, o banco para de escrever, o log do Nginx engasga e você está num SSH sem fazer ideia do que comeu o espaço. Pior: o df -h jura que está 100% cheio, você acabou de apagar um arquivo de 4 GB e nada mudou. Esse é o cenário clássico, e quase sempre ele tem uma explicação boba que você só descobre depois de sofrer.

Este guia é a sequência prática que eu sigo quando preciso achar o que está ocupando o disco numa máquina Linux: do diagnóstico macro até as armadilhas que enganam até gente experiente.

Comece sempre pelo df, nunca pelo du

Antes de sair varrendo diretório, descubra qual filesystem está cheio. Rodar du na raiz inteira sem saber onde está o problema é desperdício de tempo e de I/O.

df -h

Você vai ver algo assim:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   48G    0G 100% /
/dev/sdb1       200G   12G  178G   6% /data

Pronto. O problema está em /, não em /data. Agora você sabe onde apontar o du. Esse passo parece óbvio, mas vejo gente rodando du -ah / num servidor com vários mounts e esperando dez minutos por uma resposta que o df daria em meio segundo — ele lê metadados do filesystem, então é instantâneo mesmo num disco lotado. Repare também na coluna Use% versus Avail: às vezes o disco não está cheio de dados, mas de inodes. df -i mostra isso — milhões de arquivos minúsculos (cache de sessão PHP, mails, filas) esgotam a tabela de inodes antes de encher o espaço em blocos.

df -ih

du: encontrando os maiores diretórios

Com o mount certo em mente, o du (disk usage) é a ferramenta para mapear onde o espaço foi parar. O comando que mais uso desce um nível por vez, começando exatamente do ponto que o df apontou:

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

O --max-depth=1 impede que o du despeje a árvore inteira na tela. Você vê os totais por diretório de primeiro nível, ordenados do maior para o menor (sort -rh = reverse, human-readable). Achou que /var está gordo? Desce nele:

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

E vai afunilando. É busca binária manual: cada passo elimina metade do disco, e em duas ou três iterações você chega no culpado. Se quiser a versão bruta que lista todos os arquivos e diretórios de uma vez, ordenados por tamanho:

du -ah / | sort -rh | head

Cuidado: essa variante (-a, all files) é pesada em filesystems grandes — ela percorre cada arquivo e gera I/O num servidor já sob pressão. Em produção, prefira sempre limitar ao mount problemático com --max-depth. Um detalhe que confunde: o du mede espaço em disco real (blocos alocados), então um arquivo esparso de 10 GB que ocupa 2 GB de blocos vai aparecer como 2 GB. É o esperado.

ncdu: instale isso e pare de sofrer

Opinião direta: se a máquina é sua e você pode instalar pacote, instale o ncdu (NCurses Disk Usage). Ele faz o que o du -ah | sort faz, mas interativo — você navega na árvore com as setas, entra nos diretórios, apaga direto da interface com a tecla d.

sudo apt install ncdu     # Debian/Ubuntu
sudo dnf install ncdu     # Fedora/RHEL
ncdu /var

Ele varre uma vez, monta o índice na memória e você navega instantâneo. Para investigar "por que esse disco encheu", o ncdu resolve num terço do tempo dos comandos soltos. Em servidor onde não dá pra instalar nada, dá pra varrer num host e ler em outro com ncdu -o saida.json / ncdu -f saida.json. Em 90% dos casos de disco cheio, df -h seguido de ncdu no mount problemático resolve tudo — o resto deste artigo é para os 10% em que algo está escondido.

find: caçando arquivos grandes por tamanho

Quando o problema não é um diretório inteiro e sim um ou outro arquivo gigante perdido (um core dump, um backup esquecido, um dump de banco, um log que ninguém rotacionou), o find por tamanho é mais direto:

find / -type f -size +100M 2>/dev/null

O -size +100M pega arquivos maiores que 100 mebibytes. O 2>/dev/null joga fora os erros de permissão que poluem a saída. Para ver com tamanho legível e ordenado:

find / -type f -size +100M -exec du -h {} + 2>/dev/null | sort -rh | head

Uma confusão comum aqui: o M do find é mebibyte (base 1024), enquanto muito relatório e dashboard mostra megabyte (base 1000). Cem "M" do find não são exatamente os mesmos cem "MB" de um painel de monitoramento. Ao comparar saídas em KiB/MiB com números em MB/GB, vale passar pelo conversor de unidades pra não se enganar com a diferença de base 1024 versus 1000.

Se você ainda está montando seu repertório de terminal, vale firmar a base com os comandos Linux essenciais — find, sort e pipes são exatamente o tipo de combinação que aparece toda semana em produção.

A armadilha do arquivo deletado mas ainda aberto

Essa é a que mais derruba gente competente. Você apaga um log de 5 GB, roda df -h e... continua cheio. O espaço não volta. Por quê?

No Linux, deletar um arquivo só remove a entrada de diretório (o link). Se algum processo ainda tem aquele arquivo aberto, o inode e os blocos continuam alocados até o processo fechar o descritor. O du não vê esse espaço (o arquivo não existe mais no filesystem), mas o df vê (os blocos seguem ocupados). Por isso df e du discordam — o espaço é fantasma.

Para encontrar esses arquivos zumbi:

lsof +L1

O +L1 lista arquivos abertos com link count menor que 1 — ou seja, deletados mas ainda em uso. A versão clássica que muita gente decorou:

lsof | grep deleted

Achou o processo? Você tem duas saídas: reiniciar o serviço (mais limpo) ou, se for um log que não pode parar, truncar o descritor sem matar o processo:

: > /proc/<PID>/fd/<FD>

Na dúvida, um systemctl restart no serviço culpado resolve e libera o espaço na hora.

Os suspeitos de sempre: logs, journald e Docker

Três lugares concentram 90% dos "sumiços" de espaço que eu investigo.

Logs do systemd-journald crescem sem parar se não tiverem limite — ele guarda log binário e pode comer dezenas de GB sem avisar. Cheque e limpe:

journalctl --disk-usage
sudo journalctl --vacuum-size=200M
sudo journalctl --vacuum-time=7d

O --vacuum-size=200M mantém só os 200 MB mais recentes; o --vacuum-time=7d descarta o que for mais antigo que sete dias. Dá pra limitar de vez em /etc/systemd/journald.conf com SystemMaxUse=.

O segundo grande vilão é o Docker. Imagens órfãs, containers parados, volumes anônimos e build cache se acumulam silenciosamente até comerem dezenas de GB:

docker system df
docker system prune -a --volumes

O docker system df mostra quanto cada categoria (imagens, containers, volumes, cache) ocupa antes de você sair limpando. O prune -a --volumes é agressivo — remove imagens não usadas e volumes não referenciados, então confira que nada importante depende deles. Em servidor de CI, esse comando sozinho já salvou meu disco mais vezes do que eu gostaria de admitir.

O terceiro são logs de aplicação em /var/log sem logrotate configurado. Um du -h --max-depth=1 /var/log | sort -rh mostra rápido.

Para levar

A receita é sempre a mesma, e a ordem importa mais que os comandos: df -h primeiro para achar o mount cheio (e df -ih se o espaço parece existir mas o erro persiste — pode ser inode), depois du --max-depth=1 iterativo a partir desse mount (ou ncdu, se puder) para cavar até o culpado, e find -size +100M quando o problema for um arquivo solto. Quando df e du discordarem, lembre do arquivo deletado-mas-aberto e vá de lsof +L1. E antes de culpar mistérios, cheque o óbvio: journald, Docker e logs sem rotação. Instale o ncdu numa terça-feira calma, não no meio do incêndio — ele paga o investimento na primeira emergência.

Perguntas frequentes

Por que o df mostra o disco cheio mas o du não bate?

Quase sempre é um arquivo deletado que algum processo ainda mantém aberto. O du conta arquivos que existem no filesystem; o df conta blocos alocados. Um arquivo apagado some para o du, mas seus blocos seguem ocupados até o processo soltar o descritor. Rode lsof +L1 para encontrá-lo e reinicie o processo (ou trunque o descritor em /proc/<PID>/fd/). A segunda causa possível é esgotamento de inodes, que você confere com df -i.

Qual a diferença entre du e df?

O df (disk free) reporta no nível do filesystem: total, usado e livre por mount, lendo direto os metadados. O du (disk usage) soma o tamanho dos arquivos percorrendo diretórios. df é instantâneo e dá o quadro geral; du é mais lento mas diz exatamente quais diretórios pesam. Use df primeiro para achar o mount, du depois para cavar.

Como achar arquivos maiores que 1 GB?

Use find / -type f -size +1G 2>/dev/null. Troque o número e a unidade à vontade: +500M, +1G, +2G. Lembre que o find usa base 1024 (mebibyte/gibibyte). Para ver os tamanhos ordenados, combine com -exec du -h {} + e mande para o sort -rh.

Vale instalar o ncdu em servidor de produção?

Se a política permitir, sim — ele economiza muito tempo de diagnóstico. Em máquinas que você não controla ou onde não se instala nada, os comandos du --max-depth e find -size cobrem tudo o que o ncdu faz, só que menos confortável. O ncdu não roda nada mágico por baixo: é o mesmo du com uma interface decente.