Disco cheio no Ubuntu: diferenças entre df, du e inodos
Publicado em 2026-10-26 por frfrand
Diagnóstico de espaço e de arquivos pequenos em um VPS Linux
O servidor diz «No space left on device» mas você excluiu um arquivo grande e o erro continua. Às vezes faltam bytes; outras, inodos. df e du olham o armazenamento de pontos diferentes e ajudam a entender isso.
Te mostro onde está o problema, como verificá-lo sem chutar e o que faria em uma aplicação que realmente tem usuários. Não é preciso decorar um manual inteiro para resolver uma falha concreta.
O que df, du e inodos significam na prática
df -h informa o uso dos sistemas de arquivos; du resume o espaço ocupado por diretórios; df -i revela o uso de inodos, que podem se esgotar por muitos arquivos pequenos. Também pode haver arquivos excluídos que ainda estão abertos por um processo.
Uma esclarecimento antes de mexer no servidor: se o projeto já está em produção, salve o estado que encontrou e verifique em qual usuário e máquina você vai executar os comandos. Trabalhar como root sem necessidade e mudar várias coisas de uma vez dificulta encontrar a causa de um erro.
Comandos úteis para começar
df -h
df -i
sudo du -xhd1 /var | sort -h
sudo du -xhd1 /var/log | sort -h
sudo lsof +L1 | head
journalctl --disk-usageOs caminhos, nomes de unidades e domínios são exemplos. Adapte-os ao seu serviço. Se um comando exigir permissões de administrador, revise o que muda e por quê. As consultas de diagnóstico devem vir antes das modificações.
Passo a passo, com verificações
- Identifique exatamente qual filesystem está cheio com
df -h. - Revise inodos com
df -ipara detectar muitos arquivos pequenos. - Explore pastas do mesmo filesystem com
du -xsem cruzar montagens. - Inspecione logs, backups antigos e contêineres; não apague diretórios do sistema às cegas.
- Se você apagou um arquivo enorme e o espaço não voltou, verifique se algum processo ainda o mantém aberto.
Após cada passo, verifique um resultado observável: um status, um arquivo, uma resposta HTTP ou uma entrada de log. Se encontrar uma mensagem inesperada, salve-a para investigar em vez de escondê-la com reinicializações repetidas.
Exemplo real: uma aplicação que precisa ser mantida
Um serviço de geração de faturas cria milhares de PDFs temporários e nunca os limpa. O disco se esgota mesmo que o PostgreSQL ocupe pouco. A solução passa por política de retenção e alertas, não apenas por aumentar o volume.
Ao final, teste o caminho completo: entre pelo domínio, chame a API, escreva um dado de teste e verifique se a informação continua lá após uma reinicialização controlada. Um servidor que «arranca» nem sempre é uma aplicação que funciona.
Erros que vale a pena evitar
Nunca execute comandos destrutivos de limpeza copiados sem revisar caminhos. Apagar arquivos internos do PostgreSQL ou Docker diretamente pode corromper dados.
Também é importante que as credenciais não terminem no histórico do terminal, logs, arquivos compartidos ou capturas. Para usuários e serviços, use permissões mínimas e documente quem pode revogar o acesso.
Como o ArduMaker entra neste cenário
No ArduMaker, monitore o disco do VPS e separe diretórios temporários, bancos e backups. Um processo sem limite de arquivos pode afetar todos os projetos compartilhados.
O ArduMaker pode ajudar você a administrar os VPS, implantar repositórios e trabalhar com serviços, bancos e domínios a partir da mesma plataforma. Não substitui o que acabamos de explicar sobre o Linux: precisamente por isso, convém entender o diagnóstico e ter uma forma de repeti-lo.
Quando convém automatizá-lo
Se a tarefa se repetir, documente primeiro o procedimento manual e suas verificações. Depois, considere um script ou uma tarefa agendada com erros visíveis, logs e permissões limitadas. Não automatize um comando que você ainda não saiba recuperar quando algo der errado.
Perguntas frequentes
Posso testá-lo sem afetar clientes? Em muitos casos, sim: um VPS de staging ou um serviço de teste separado permite validar a configuração antes de alterar a produção.
Como saber se ficou certo? Verifique logs e uma operação funcional, não apenas se o comando terminou com código zero.
Quando preciso de mais recursos? Quando as métricas indicarem saturação de CPU, RAM, disco ou conexões. Uma falha de configuração raramente se resolve contratando mais memória.
Referências
Em uma frase: primeiro entenda o erro, depois altere uma coisa concreta e comprove seu efeito. Essa disciplina economiza muitas horas de suporte.