Como investigar "No Space Left on Device" no Ubuntu

2025-12-15 Tempo de leitura: Cerca de 10 min Dificuldade: Intermediario

O que voce vai aprender

• Como identificar rapidamente o que esta consumindo espaco em disco quando o servidor Ubuntu reporta "disco cheio"
• Entender quando usar df vs du
• Passos para resolver logs inflados (Nginx/Apache, WordPress, Docker, systemd journal)

1. Primeiro, verifique qual area esta cheia (df)

Conclusao: Execute df -h e df -ih primeiro para identificar o ponto de montagem cheio.

$ df -h

Pontos-chave para observar

• Linhas com Use% alto (acima de 90%)
• Mounted on (onde esta montado)

Padroes comuns

• / (raiz) esta cheio
• /var esta em uma particao separada e esta cheio (logs e dados de servicos se acumulam aqui)
• /var/lib/docker esta inflado ao usar Docker

Verifique tambem esgotamento de inodes (muitos arquivos)

Se voce ainda recebe erros "no space" apesar de ter capacidade disponivel, pode ser esgotamento de inodes.

$ df -ih

Se IUse% esta alto (proximo de 100%), voce provavelmente tem muitos arquivos pequenos.

2. Descubra o que esta crescendo (du)

Conclusao: Execute du -x -h -d 1 a partir da montagem cheia e aprofunde ate o maior diretorio.

Uma vez que voce sabe qual ponto de montagem esta cheio pelo df, use du para restringir a causa.

Obter visao geral dos grandes diretorios sob a raiz

(Quando a raiz / esta cheia)

$ sudo du -x -h -d 1 / | sort -h

• -x: Nao cruzar limites de montagem (mais facil de isolar a causa)
• -d 1: Profundidade de 1 nivel (comece de forma ampla)
• sort -h: Ordenar por tamanho

Se voce ver diretorios grandes (ex.: /var, /home), aprofunde neles a seguir.

Quando /var e grande (logs, Docker, banco de dados se acumulam aqui)

$ sudo du -x -h -d 1 /var | sort -h

Candidatos comuns de inchacho

• /var/log (logs)
• /var/lib (Docker, dados de banco)
• /var/cache (cache)

3. Resolver logs inflados (/var/log e systemd journal)

Conclusao: Verifique /var/log com find e journalctl --disk-usage antes de qualquer exclusao.

Verificar tamanho de /var/log

$ sudo du -h -d 1 /var/log | sort -h

Encontrar arquivos grandes:

$ sudo find /var/log -type f -printf "%s %p\n" | sort -n | tail -n 20

Causadores comuns

• Nginx: /var/log/nginx/access.log error.log
• Apache: /var/log/apache2/access.log error.log
• Sistema: /var/log/syslog auth.log

Verificar tamanho do journal do systemd (journalctl)

No Ubuntu, o journal (logs binarios) pode ficar inflado.

$ sudo journalctl --disk-usage

4. Verificacao do ambiente Docker (ponto de entrada para inchacho de log/imagem)

Conclusao: Execute docker system df — identifique qual categoria do Docker e grande antes de limpar.

Ambientes Docker tendem a consumir espaco com logs, imagens e volumes.

Verificar uso geral do Docker

$ docker system df

• Identifique qual de Images / Containers / Local Volumes e grande

5. Resposta de emergencia (abordagem segura): libere espaco primeiro

Conclusao: Use journalctl --vacuum-size=1G para alivio rapido, depois corrija a causa raiz.

Sem resolver a causa raiz (logging continuo, erros persistentes), o problema vai se repetir. Porem, em emergencias, voce precisa liberar espaco primeiro para restaurar os servicos.

Excluir journal antigo para limitar a capacidade (relativamente seguro)

Exemplo para limitar a 1GB no maximo:

$ sudo journalctl --vacuum-size=1G

Abordagem por dias (excluir logs com mais de 7 dias):

$ sudo journalctl --vacuum-time=7d

Quando os logs continuam crescendo de forma anormal (entrada da causa raiz)

Se Nginx/Apache/WordPress continua gerando erros, os logs vao continuar crescendo e o problema vai se repetir.

• Logs de erro do Nginx/Apache (error.log)
• Logs de erro do WordPress/PHP-FPM
• Logs de excecao da aplicacao

Primeiro identifique quais erros estao se repetindo, depois pare/corrija o servico causador.

6. Verificacao

Conclusao: Execute df -h e df -ih novamente apos a correcao para confirmar que o uso melhorou.

Apos fazer alteracoes, sempre verifique a melhoria com df.

$ df -h
$ df -ih