É seguro rodar 'docker system prune -a'?

Ele remove contêineres parados, redes sem uso, cache de build órfão e toda imagem que nenhum contêiner em execução usa. Seus dados ficam, a menos que você adicione --volumes. Com --volumes ele também apaga volumes sem uso — e o volume de um contêiner de banco de dados parado conta como sem uso. Evite essa flag se não tiver certeza.

Apaguei um log enorme, mas o df ainda mostra o disco cheio. Por quê?

Um processo em execução ainda mantém o arquivo aberto, então o kernel não libera o espaço. Encontre-o com 'lsof +L1' e reinicie esse serviço. Da próxima vez, esvazie um log ativo com 'truncate -s 0 arquivo' em vez de apagá-lo.

Quanto espaço livre devo manter?

Pelo menos 10–15%. Bancos de dados, atualizações de pacotes e pulls do Docker precisam de espaço temporário, e um disco a 100% pode corromper um banco no meio de uma escrita.

Dá para aumentar o disco sem reinstalar?

Sim. Migrar para um plano maior aumenta o disco no lugar e mantém seus dados — Nano tem 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. O upgrade reinicia o servidor uma vez.

O que costuma encher um VPS pequeno?

Pela nossa experiência: imagens e cache de build do Docker, o journal do systemd, logs de aplicação que ninguém rotaciona e dumps de banco ou arquivos de backup esquecidos em /root.

Como liberar espaço em disco num VPS sem quebrar nada

Disco cheio no VPS? Descubra o que ocupa espaço com du e ncdu e limpe cache do apt, journal, sobras do Docker e logs sem perder dados.

"No space left on device" nunca aparece numa hora boa. O banco de dados para de aceitar escritas, o apt não consegue terminar uma atualização e o Docker se recusa a baixar justamente a imagem de que você precisa agora. A boa notícia: num VPS pequeno, o culpado quase sempre é uma de cinco coisas, e você o encontra em dois minutos.

1. Qual é o tamanho do problema?

df -h /
df -i /

A primeira linha mostra o espaço usado. A segunda mostra os inodes — se os inodes chegam a 100% enquanto o espaço parece ok, você tem milhões de arquivos minúsculos (arquivos de sessão, uma fila de e-mail, uma pasta de cache). Problema diferente, mesmo sintoma.

2. Descubra o que é grande

Percorra a árvore de cima para baixo e ordene por tamanho:

du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15

-x fica num único sistema de arquivos, então não entra em /proc. Depois aprofunde no que for maior. Para navegar de forma interativa, o ncdu é bem mais agradável:

apt install -y ncdu
ncdu -x /

Setas para navegar, d para apagar. Cuidado com essa última.

3. As vitórias rápidas

São seguras em qualquer servidor Ubuntu ou Debian:

apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M

O apt autoremove também remove kernels antigos. O journal do systemd é o que pega todo mundo de surpresa — sem limite, pode crescer até vários gigabytes. Para limitá-lo de vez, defina SystemMaxUse=200M em /etc/systemd/journald.conf e rode systemctl restart systemd-journald.

4. Sobras do Docker

Se você usa Docker, olhe aqui primeiro. Imagens antigas e cache de build se acumulam a cada deploy:

docker system df
docker image prune -a
docker builder prune

docker image prune -a apaga imagens que nenhum contêiner em execução usa. Normalmente é o que você quer, mas o próximo deploy vai baixá-las de novo.

O perigoso é docker system prune -a --volumes. Volumes guardam seus dados, e um volume ligado a um contêiner parado conta como sem uso. É assim que gente perde banco de dados. Não cole isso de uma resposta de fórum.

O outro devorador escondido são os logs dos contêineres. Limite-os em /etc/docker/daemon.json:

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

Reinicie o Docker depois disso. O limite só vale para contêineres criados a partir daí, então recrie os mais barulhentos com docker compose up -d --force-recreate.

5. Logs e arquivos esquecidos

Encontre arquivos grandes em qualquer lugar do disco:

find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null

Os achados de sempre: um backup.tar.gz de seis meses atrás em /root, um dump de banco que alguém ia baixar, um log de aplicação que nunca é rotacionado.

Num log em que um serviço ainda está escrevendo, não use rm — esvazie-o:

truncate -s 0 /var/log/myapp/app.log

Se você já apagou um e o espaço não voltou, algum processo ainda o mantém aberto:

lsof +L1

Reinicie o serviço listado e o espaço volta.

Quando limpar não basta

Às vezes os dados são simplesmente reais — um banco que cresce, uploads de usuários, um arquivo de modelo. Aí a solução honesta é mais disco. O upgrade de plano aumenta o disco no lugar e mantém tudo: Nano tem 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. O servidor reinicia uma vez. Os detalhes estão na documentação dos planos.

Mais uma coisa que ocupa espaço em silêncio: o arquivo de swap. Se você seguiu nosso guia de swap, esses 1–2 GB estão lá de propósito. E se o Docker é o maior consumidor, o guia de instalação do Docker e o guia de stacks Compose mostram como manter as imagens sob controle.

O hábito que evita tudo isso: limite o journal e os logs do Docker no primeiro dia. Duas linhas de configuração, e o "disco cheio" praticamente deixa de acontecer.