Disco do Servidor a 100%? O Teu Guia Prático para Limpar o journald, Docker overlay2 e Inodes Esgotados

O Alerta das 03:00 da Manhã: ‘No Space Left on Device’

Não há incidente operacional mais frequente—nem mais frustrante—do que um servidor Linux de produção atingir os 100% de utilização de disco. Num instante, bases de dados como PostgreSQL e MySQL entram em modo de recuperação só de leitura, o Redis bloqueia ao tentar tirar snapshots, o Nginx rejeita novos visitantes porque não consegue gravar buffers temporários e tu ficas impedido de autocompletar comandos na consola.

O primeiro instinto de quem tem menos experiência é entrar em pânico e disparar comandos perigosos de rm -rf pelas pastas do sistema, apagando ficheiros vitais de sockets, bases de dados em curso ou quebrando tabelas do Docker. Em servidores Debian, recuperar uma máquina com disco cheio exige um método clínico de diagnóstico.

ANATOMIA DE UMA EMERGÊNCIA DE DISCO CHEIO

• O TEU DISCO ATINGE OS 100%: [ PostgreSQL / MySQL ] → Não Consegue Gravar WALs → Bloqueio de Emergência
• Servidor Nginx: Sem Espaço para Buffers → Erros HTTP 500 aos Clientes
• Logs do Sistema: Falha ao Gravar Eventos → Cegueira Operacional Total
• O GUIA SEGURO DE RECUPERAÇÃO: 1. Distinguir Falta de Blocos (df -h) de Falta de Inodes (df -i)
• 2. Limpar os Registos Acumulados do systemd-journald
• 3. Recuperar Espaço no Docker com Prune Nativo
• 4. Trancar Ficheiros Apagados Presos em Memória (lsof +L1)

Na Webxtek, mantemos infraestruturas críticas sob contratos de manutenção contínua que monitorizam o crescimento do armazenamento para prevenir falhas antes que os clientes as sintam. Se a tua empresa enfrenta incidentes frequentes de capacidade, a nossa consultoria técnica ajuda-te a desenhar uma infraestrutura resiliente.

Diagnóstico: Falta de Espaço em Disco ou Inodes Esgotados?

Antes de apagares qualquer ficheiro, precisas de saber se o teu problema é espaço em gigabytes ou esgotamento de inodes.

Nos sistemas de ficheiros de Linux (como ext4 ou XFS), cada ficheiro, pasta ou link simbólico precisa de uma estrutura de metadados chamada inode. Se uma aplicação com erros criar milhões de ficheiros minúsculos com zero bytes (como sessões antigas de PHP ou lixo de emails), o teu sistema de ficheiros esgota todos os inodes disponíveis, mesmo que ainda tenhas centenas de gigabytes vazios.

# Inspeciona o espaço físico do disco (em Gigabytes)
df -h /

# Inspeciona a percentagem de inodes utilizados (Número de Ficheiros)
df -i /

BLOCOS DE DISCO VS. ESGOTAMENTO DE INODES

• FALTA DE ESPAÇO FÍSICO (df -h = 100%): Causas: Logs gigantescos sem rotação, imagens antigas de Docker, bases de dados.
• Solução: Limpar logs antigos, imagens desnecessárias e ficheiros temporários.
• ESGOTAMENTO DE INODES (df -i = 100% com dezenas de GB livres no df -h!): Causas: Milhões de pequenas sessões de PHP, spools de email ou lixo de cache.
• Solução: Descobrir as pastas mais povoadas e apagar ficheiros em massa.

Se o teu df -i mostrar 100% de inodes ocupados, usa este comando para descobrires a pasta que está a afogar o disco:

# Descobre as 15 pastas com maior número de ficheiros individuais
find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -k1 -n | tail -n 15

Como Limpar os Gigabytes Acumulados no systemd-journald

Em distribuições Linux modernas, o systemd-journald regista todas as mensagens de aplicações, do kernel e de serviços. Se não tiver limites definidos, o journald pode ocupar facilmente até 10% de todo o teu disco, acumulando dezenas de gigabytes de eventos antigos.

Segundo a documentação do systemd, nunca deves apagar ficheiros em /var/log/journal/ com o comando rm. Usa sempre o comando nativo journalctl para fazer a purga segura:

# Vê o espaço exato ocupado pelos logs do journald
journalctl --disk-usage

# Apaga imediatamente os registos com mais de 3 dias
journalctl --vacuum-time=3d

# Ou limita o tamanho total histórico a um máximo de 500MB
journalctl --vacuum-size=500M

Para evitares que o journal volte a crescer descontroladamente no futuro, edita /etc/systemd/journald.conf:

[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=500M
SystemMaxFileSize=50M
MaxRetentionSec=1month

Aplica a configuração instantaneamente:

systemctl restart systemd-journald

Limpeza Segura do Docker overlay2 sem Corromper Containers

Em servidores que correm containers, a pasta /var/lib/docker/overlay2 costuma ser a maior devoradora de disco. Durante atualizações contínuas de código, acumulam-se imagens órfãs, camadas de compilação intermédias e volumes sem nome.

Nunca corras rm -rf /var/lib/docker/overlay2/*! Esse erro destrói a base de dados interna do Docker, fazendo com que o serviço deixe de arrancar. Usa sempre os comandos de limpeza do próprio Docker:

FLUXO DE RECUPERAÇÃO DE ESPAÇO NO DOCKER

• 1. Analisa o Espaço Real Gasto por Cada Categoria docker system df
• 2. Remove Containers Parados e Imagens Órfãs docker system prune -f
• 3. Limpa a Cache de Compilação Multi-Etapas (Costuma Ter Dezenas de GB!) docker builder prune -a –force –filter “until=48h”
• 4. Remove Volumes Anónimos Sem Utilização docker volume prune -f

Além disso, os ficheiros de log em JSON dos containers podem crescer sem fim se não definires um limite global no ficheiro /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "20m",
    "max-file": "3"
  }
}

Recarrega as configurações com systemctl reload docker para que todos os novos containers criados respeitem esta rotação.

O Mistério dos Ficheiros Apagados mas Ainda Presos em Memória

Um dos problemas mais estranhos em Linux acontece quando corres du -sh /* e o comando diz que tens apenas 20GB de dados no disco, mas o df -h garante que a tua partição de 100GB está a 100% de uso.

Isto acontece porque quando apagas um ficheiro com rm, apenas apagas o nome dele na pasta. Se um processo ativo (como o Nginx ou o Python) ainda tiver esse ficheiro aberto em memória, o kernel recusa-se a libertar os blocos de disco até que esse processo termine.

FICHEIRO APAGADO MAS PRESO EM MEMÓRIA POR PROCESSO

1. Executas: rm /var/log/nginx/access.log (Ficheiro com 20GB)

• 2. O Nome do Ficheiro Desaparece da Pasta, MAS o Nginx Continua a Escrever Nele
• 3. O Kernel do Linux Mantém os 20GB Ocupados em Estado Invisível
• du -sh diz que o ficheiro já não existe df -h continua a mostrar 100% de disco cheio!

Para resolveres este problema sem teres de reiniciar o teu servidor:

# Lista todos os ficheiros apagados que continuam abertos em memória
lsof +L1

# Exemplo de saída:
# COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF   NLINK   NAME
# nginx   14820   root    3w   REG  254,1  21474836480   0   /var/log/nginx/access.log (deleted)

Em vez de matares o processo à força, podes esvaziar o descritor diretamente no sistema /proc:

# Esvazia o ficheiro preso a 0 bytes imediatamente
: > "/proc/14820/fd/3"

Os 20GB de espaço regressam ao teu disco no mesmo segundo, sem que nenhuma ligação de clientes caia.

Aliando esta disciplina técnica aos nossos serviços de alojamento gerido, garantes que os teus servidores Linux trabalham sempre com margem de segurança e monitorização contínua.

Na prática, aplicas exatamente estes padrões operacionais em setores exigentes como especialistas em devops e arquitetura cloud e provedores de cloud computing e iaas. Quando alinhas a tua estrutura através de manutenção de website e cuidado técnico e alojamento gerido para websites e aplicações, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.