Limpeza de Disco — VM Oracle Cloud

Data: 2025-05-06
Servidor: Oracle Cloud VPS (Ubuntu)
Disco: /dev/sda1 — 193GB
Situação inicial: 116GB usados (60%) → Situação final: 45GB usados (23%)

---

1. Diagnóstico

1.1 Visão geral do disco

df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       193G  116G   77G  61% /

1.2 Identificação dos maiores diretórios

sudo du -h --max-depth=1 / 2>/dev/null | sort -hr | head -20

Resultado relevante:

Diretório	Tamanho
/var	130GB
/home	3.4GB
/usr	2.1GB
/snap	1.9GB

1.3 Investigação do /var

sudo du -h --max-depth=2 /var 2>/dev/null | sort -hr | head -20

Resultado relevante:

Diretório	Tamanho
/var/lib/docker	125GB
/var/log/journal	3.7GB
/var/lib/snapd	746MB

1.4 Investigação do Docker

sudo du -h --max-depth=2 /var/lib/docker 2>/dev/null | sort -hr | head -20
docker system df

Achado crítico: um único diretório de container ocupava 71GB:

/var/lib/docker/containers/752e56658280...   71GB

---

2. Causa Raiz

O container GitLab (gitlab/gitlab-ce:latest, nome /Gitlab) havia sido removido em abril, mas seu diretório de logs em /var/lib/docker/containers/ não foi deletado, acumulando 71GB em um único arquivo *-json.log.

Adicionalmente, o processo dockerd mantinha o arquivo aberto via file descriptor, impedindo que o espaço fosse liberado pelo sistema operacional mesmo após o rm.

# Verificação do arquivo órfão
ls -lh /var/lib/docker/containers/752e56658280.../
# -rw-r----- 1 root root 71G May 6 17:18 752e...-json.log

# Verificação do container (não existia mais)
docker inspect 752e56658280
# Error: No such object

---

3. Correção

3.1 Remoção do diretório órfão

sudo rm -rf /var/lib/docker/containers/752e56658280a7cea159a5f875591a4eae29706f441bbab4e45dd4443d512246/

3.2 Limpeza geral do Docker

docker system prune -a --volumes

Remove imagens sem container ativo, build cache e volumes não associados.

3.3 Liberação imediata do espaço (sem downtime)

O dockerd ainda mantinha o arquivo deletado aberto (file descriptor 79). O espaço só seria liberado após reiniciar o serviço — ou truncando o fd diretamente:

# Identificar o processo e fd
sudo lsof | grep deleted | grep docker

# Truncar sem derrubar containers
sudo truncate -s 0 /proc/920394/fd/79

⚠️ A alternativa com downtime seria sudo systemctl restart docker, que libera o fd ao reiniciar o serviço, mas interrompe todos os containers temporariamente.

---

4. Resultado

df -h /

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       193G   45G  149G  23% /

70GB liberados sem nenhum downtime.

---

5. Prevenção — Limite de Logs no Docker

Para evitar que logs de containers cresçam indefinidamente, configure rotação automática no daemon do Docker.

5.1 Editar /etc/docker/daemon.json

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

Isso limita cada container a no máximo 300MB de logs (3 arquivos × 100MB), com rotação automática.

5.2 Aplicar a configuração

sudo systemctl reload docker

5.3 Verificar

docker info | grep "Logging Driver"
# Logging Driver: json-file

⚠️ A configuração de log-opts se aplica apenas a novos containers. Containers já existentes precisam ser recriados (docker compose down && docker compose up -d) para herdar o novo limite.

---

6. Referência Rápida — Comandos de Diagnóstico

# Visão geral do disco
df -h

# Maiores diretórios (recursivo)
sudo du -h --max-depth=1 / 2>/dev/null | sort -hr | head -20

# Uso do Docker
docker system df

# Arquivos deletados ainda abertos
sudo lsof | grep deleted

# Limpeza geral do Docker (imagens, cache, volumes órfãos)
docker system prune -a --volumes