Como investigar "No Space Left on Device" no Ubuntu

2025-12-15 Tempo de leitura: Cerca de 10 min Dificuldade: Intermediário

O que você vai aprender

• Como identificar rapidamente o que está consumindo espaço 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 área está cheia (df)

Conclusão: 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 está montado)

Padrões comuns

• / (raiz) está cheio
• /var está em uma partição separada e está cheio (logs e dados de serviços se acumulam aqui)
• /var/lib/docker está inflado ao usar Docker

Verifique também esgotamento de inodes (muitos arquivos)

Se você ainda recebe erros "no space" apesar de ter capacidade disponível, pode ser esgotamento de inodes.

$ df -ih

Se IUse% está alto (próximo de 100%), você provavelmente tem muitos arquivos pequenos.

2. Descubra o que está crescendo (du)

Conclusão: Execute du -x -h -d 1 a partir da montagem cheia e aprofunde até o maior diretório.

Uma vez que você sabe qual ponto de montagem está cheio pelo df, use du para restringir a causa.

Obter visão geral dos grandes diretórios sob a raiz

(Quando a raiz / está cheia)

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

• -x: Não cruzar limites de montagem (mais fácil de isolar a causa)
• -d 1: Profundidade de 1 nível (comece de forma ampla)
• sort -h: Ordenar por tamanho

Se você ver diretórios grandes (ex.: /var, /home), aprofunde neles a seguir.

Quando /var é 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)

Conclusão: Verifique /var/log com find e journalctl --disk-usage antes de qualquer exclusão.

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 binários) pode ficar inflado.

$ sudo journalctl --disk-usage

4. Verificação do ambiente Docker (ponto de entrada para inchacho de log/imagem)

Conclusão: Execute docker system df — identifique qual categoria do Docker é grande antes de limpar.

Ambientes Docker tendem a consumir espaço com logs, imagens e volumes.

Verificar uso geral do Docker

$ docker system df

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

5. Resposta de emergência (abordagem segura): libere espaço primeiro

Conclusão: Use journalctl --vacuum-size=1G para alívio rápido, depois corrija a causa raiz.

Sem resolver a causa raiz (logging continuo, erros persistentes), o problema vai se repetir. Porém, em emergências, você precisa liberar espaço primeiro para restaurar os serviços.

Excluir journal antigo para limitar a capacidade (relativamente seguro)

Exemplo para limitar a 1GB no máximo:

$ 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 vão 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 exceção da aplicação

Primeiro identifique quais erros estão se repetindo, depois pare/corrija o serviço causador.

6. Verificação

Conclusão: Execute df -h e df -ih novamente após a correção para confirmar que o uso melhorou.

Após fazer alterações, sempre verifique a melhoria com df.

$ df -h
$ df -ih