Comando df e du: descubra o que encheu o disco no Linux

Um disco cheio nunca avisa com antecedência: o serviço deixa de escrever logs, a base de dados recusa transações, os utilizadores não conseguem gravar — e o alerta chega às três da manhã. A dupla df e du é a primeira linha de resposta: o df (disk free) diz quanto espaço resta em cada sistema de ficheiros, o du (disk usage) diz quem o gastou, diretório a diretório. Um dá o sintoma, o outro encontra a causa.

Neste artigo percorremos as opções que realmente interessam, o caso clássico em que o df e o du discordam — e o que isso tem que ver com segurança — e terminamos com um simulador interativo onde pode investigar um /var quase cheio sem arriscar nenhum servidor.

O que fazem o df e o du

Os dois comandos respondem a perguntas diferentes e usam métodos diferentes. O df pergunta ao kernel os totais de cada sistema de ficheiros montado — blocos totais, ocupados e livres, lidos diretamente do superbloco — e por isso responde num instante. O du percorre uma árvore de diretórios ficheiro a ficheiro e soma os blocos que cada um ocupa; numa árvore grande pode demorar, mas é o único que diz onde está o espaço.

df [opções] [caminho]
du [opções] [diretório]

Detalhe importante: quando o df recebe um caminho como argumento, não mede esse diretório — mostra o sistema de ficheiros onde o caminho vive. Para medir um diretório concreto, o comando certo é o du.

As opções que interessam

df: o disco visto de cima

• -h — tamanhos legíveis (K, M, G) em vez de blocos de 1K. O df -h é o primeiro comando de qualquer diagnóstico de espaço.
• -i — conta inodes em vez de blocos. Cada ficheiro consome um inode; milhões de ficheiros minúsculos esgotam-nos antes do espaço, e o resultado é «No space left on device» com o disco meio vazio.
• -T — acrescenta o tipo de sistema de ficheiros: ext4, xfs, tmpfs. Saber que um ponto de montagem é tmpfs (vive em RAM) muda tudo numa investigação.
• df /var — com um caminho, mostra apenas o sistema de ficheiros dessa partição. Ideal para vigiar a que interessa.
• -x tmpfs — exclui um tipo; --total — acrescenta a soma de tudo.

df -h /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        20G   19G  794M  96% /var

du: quem gastou o espaço

• -s — só o total de cada argumento; com -h forma o clássico du -sh /var, a resposta a «quanto pesa esta pasta?».
• --max-depth=1 (ou -d 1) — agrega por subdiretório de primeiro nível. É assim que se desce na árvore: o número maior indica o próximo passo.
• -a — inclui ficheiros e não só diretórios; combinado com sort -rn e head produz o «top» dos maiores ocupantes.
• -x — não atravessa outros sistemas de ficheiros montados dentro da árvore, para não somar o que pertence a outra partição.
• -c — total geral no fim; --exclude=PADRÃO — ignora caminhos; --apparent-size — tamanho lógico em vez de blocos ocupados (relevante em ficheiros sparse).

du -h --max-depth=1 /var
11G     /var/log
4.3G    /var/www
2.1G    /var/lib
19G     /var

du -a /var | sort -rn | head -3
19482812  /var
11143393  /var/log
9316569   /var/log/nginx

Quando o df e o du discordam

É o cenário que mais confunde: o df diz que a partição está a 96%, o du só encontra metade desse espaço. A causa habitual é um ficheiro apagado que um processo ainda tem aberto. Ao fazer rm a um log gigante enquanto o serviço continua a escrever nele, o nome desaparece do diretório — e o du deixa de o ver — mas o kernel só liberta os blocos quando o último descritor fechar. O df, que lê os totais reais do sistema de ficheiros, continua a contá-los.

lsof +L1 /var
COMMAND  PID     USER FD  TYPE DEVICE   SIZE/OFF NLINK   NODE NAME
nginx   1204 www-data  5w  REG    8,2 8697308160     0 526012 /var/log/nginx/access.log (deleted)

A solução é fechar o descritor — reiniciar ou recarregar o serviço — ou, melhor ainda, prevenir: truncate -s 0 ficheiro esvazia um log aberto sem o apagar, e o espaço liberta-se de imediato. Outra fonte de discrepância são os blocos reservados ao root no ext4 (5% por omissão, ajustáveis com tune2fs -m): explicam um df «cheio» quando as contas não batem certo por uma pequena margem.

df e du em cibersegurança

Disco a encher como sintoma de ataque. Um access.log que cresce gigabytes em horas raramente é tráfego legítimo: scraping agressivo, força bruta contra formulários de autenticação ou fuzzing de rotas geram volume de log muito acima do normal. Antes de apagar o ficheiro que encheu o disco, vale a pena perguntar porquê — o log é simultaneamente o problema e a evidência.

Preparação de exfiltração. Um atacante que comprime dados para exfiltrar precisa de espaço temporário: arquivos volumosos a aparecer em /tmp, /var/tmp ou diretórios de upload são um sinal clássico. Um du -a ordenado por tamanho, corrido regularmente e comparado com a linha de base, denuncia estes ficheiros em segundos.

Binários apagados ainda em execução. Malware que se apaga do disco depois de arrancar continua vivo em memória — exatamente o padrão que o lsof +L1 revela. Em resposta a incidentes, a discrepância entre df e du pode ser a primeira pista de que algo correu e escondeu o rasto.

Inodes e negação de serviço. Encher uma partição de ficheiros minúsculos — sessões, caches, filas de mail — esgota os inodes e trava o serviço com espaço de sobra. O df -i deteta-o; quota e repquota impõem limites por utilizador e contêm o estrago, seja ele acidental ou malicioso.

Experimente no simulador interativo

A simulação abaixo recria uma máquina com cinco sistemas de ficheiros e um /var a 96%. No painel esquerdo vê os discos montados e a árvore do /var com tamanhos; no terminal à direita, cada comando executa-se com o resultado calculado ao vivo. Clique nas opções do df e do du para compor comandos, siga o cenário do «espaço preso» (rm do log, lsof +L1, reinício do serviço), use Demonstrar tudo para a investigação guiada completa ou avance passo a passo com Anterior e Seguinte. A nota por baixo dos botões explica cada passo.

Erros comuns e boas práticas

• Confundir as perguntas: df /var/log não mede o diretório — mostra a partição inteira. Para medir o diretório, du -sh /var/log.
• Apagar um log aberto com rm e concluir que «não libertou espaço». Use truncate -s 0, recarregue o serviço, ou configure logrotate com copytruncate.
• Correr o du sem privilégios: diretórios ilegíveis ficam fora da soma e o total sai subestimado. Em áreas de sistema, corra com sudo.
• Esquecer o -x e somar partições montadas dentro da árvore — o total deixa de corresponder ao sistema de ficheiros que está cheio.
• Ignorar os inodes: perante «No space left on device» com espaço livre, o reflexo certo é df -i.
• Apagar em pânico: num incidente, o ficheiro que encheu o disco é evidência. Copie ou preserve antes de limpar — a forense agradece.
• Estranhar 5% «desaparecidos» no ext4: são os blocos reservados ao root, pensados para o sistema não parar quando os utilizadores enchem o disco.

---

Conclusão

O fluxo é sempre o mesmo: df -h para o sintoma, du --max-depth=1 para descer até ao culpado, du -a | sort -rn | head para o apanhar, lsof +L1 quando os números não batem certo e df -i quando o espaço livre engana. Cinco comandos que transformam um alerta de disco cheio numa investigação de minutos — e, às vezes, na primeira pista de um incidente de segurança. Se gere servidores, veja também o nosso artigo sobre o useradd.

Quer treinar estas competências com casos reais, ou precisa de apoio especializado em administração de sistemas e segurança? Conheça os serviços de formação e consultoria da HJFR no nosso catálogo de serviços — desenhamos percursos práticos para equipas técnicas e programas à medida para empresas.

Este artigo faz parte da série «Comandos Linux, um a um» do blog HJFR — fique atento aos próximos comandos.