Disco cheio no Linux: como ver o que ocupa espaço na VPS

Resposta rápida: para ver o espaço em disco no Linux, rode df -h. Para descobrir o que está ocupando, use sudo du -xh --max-depth=1 / | sort -h e desça pela maior pasta, ou navegue com sudo ncdu -x /. Os suspeitos mais comuns são journal, logs, cache do apt, imagens do Docker e backups esquecidos. Se o df mostra disco cheio e o du não acha nada, procure arquivos apagados ainda abertos com sudo lsof +L1.

Comece pelo df: o que encheu

df -hT
df -i

Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/sda1      ext4    39G   37G  1.6G  96% /
tmpfs          tmpfs  197M  1.1M  196M   1% /run

Olhe a linha montada em /, a raiz, onde o problema está em quase todos os casos. As linhas tmpfs ficam na memória e não ocupam disco. O nome do disco (/dev/sda1, /dev/vda1) varia conforme a VPS. Se Size menos Used não bate com Avail, é normal: o ext4 reserva cerca de 5% para o root conseguir trabalhar com o disco cheio.

O df -i mostra os inodes, as entradas que o sistema usa para cada arquivo. Se IUse% está em 100% com espaço sobrando, o problema são milhões de arquivos pequenos: sessões de PHP, cache ou fila de e-mail. Para achar onde, conte arquivos em vez de bytes:

Aja cedo: com o disco cheio, o banco para de gravar, aplicações falham e atualizações do apt quebram no meio.

As pastas mais pesadas com du e ncdu

O du soma o tamanho de cada pasta. Olhe um nível por vez e desça sempre pela maior:

sudo du -xh --max-depth=1 / 2>/dev/null | sort -h
sudo du -xh --max-depth=1 /var 2>/dev/null | sort -h
sudo du -xh --max-depth=1 /var/lib 2>/dev/null | sort -h

O -x não entra em outros sistemas de arquivos, o -h mostra tamanhos legíveis e o sort -h põe a maior pasta por último. Para investigar com mais conforto, o ncdu varre uma vez e deixa você navegar com as setas:

sudo apt install -y ncdu
sudo ncdu -x /

Enter entra na pasta, a seta para a esquerda volta, d apaga (com confirmação) e q sai.

Atenção: não apague nada dentro de /var/lib/mysql, /var/lib/postgresql ou /var/lib/docker com rm ou pelo ncdu. Esses diretórios são controlados pelos próprios programas, e remover arquivos na mão corrompe o banco ou o Docker. A limpeza deles é feita pelos comandos mostrados mais abaixo.

Arquivos grandes com find

# arquivos acima de 500 MB, do maior para o menor
sudo find / -xdev -type f -size +500M -exec du -h {} + 2>/dev/null | sort -rh | head -n 20

# arquivos acima de 100 MB alterados nos últimos 7 dias
sudo find / -xdev -type f -size +100M -mtime -7 -exec ls -lh {} + 2>/dev/null

# dumps e backups compactados esquecidos
sudo find / -xdev -type f \( -name "*.sql" -o -name "*.sql.gz" -o -name "*.tar.gz" -o -name "*.zip" \) -size +100M -exec du -h {} + 2>/dev/null | sort -rh

O segundo comando é o melhor quando o disco encheu de repente: o culpado quase sempre é recente.

Os suspeitos de sempre

# journal
journalctl --disk-usage
sudo journalctl --vacuum-size=200M

# cache do apt e kernels antigos
sudo apt clean
sudo apt autoremove --purge

# snaps: manter só duas revisões daqui em diante
snap list --all | awk '/disabled/{print $1, $3}'
sudo snap remove NOME_DO_SNAP --revision=NUMERO
sudo snap set system refresh.retain=2

Para o journal não voltar a crescer, defina SystemMaxUse=200M em /etc/systemd/journald.conf e rode sudo systemctl restart systemd-journald. Evite rm em /var/log inteiro: alguns serviços, como o Nginx, nem iniciam se a pasta de log sumir. Apague arquivos, não a estrutura.

Docker: imagens, volumes e logs

Em VPS com containers, o Docker é o culpado mais frequente. Cada deploy baixa uma imagem nova e a antiga fica, o cache de build cresce e o log de cada container cresce sem limite na configuração padrão.

docker system df
docker container prune   # containers parados
docker image prune -a    # imagens que nenhum container usa
docker builder prune     # cache de build

Volumes guardam dados de banco e uploads. Liste com docker volume ls, confira a quem pertence cada um e só então remova o que for lixo. Nunca rode limpeza de volumes no automático.

Para limitar o log dos containers, crie ou edite /etc/docker/daemon.json:

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

Reinicie com sudo systemctl restart docker. O limite vale só para containers criados depois; recrie os existentes, por exemplo com docker compose up -d --force-recreate.

df mostra cheio, mas o du não acha nada

A causa mais comum é um arquivo apagado que continua aberto por algum processo. Alguém removeu um log de 10 GB com rm enquanto o serviço ainda escrevia nele: o nome sumiu, mas o Linux só libera o espaço quando o processo fecha o arquivo.

A lista mostra arquivos marcados como deleted, com o processo (COMMAND e PID) e o tamanho. A solução mais limpa é reiniciar o serviço dono do arquivo com systemctl restart. Se não puder reiniciar agora, esvazie pelo descritor, usando o número da coluna FD sem a letra:

# exemplo: PID 1234 e FD 3w na saída do lsof
sudo truncate -s 0 /proc/1234/fd/3

Para não cair nisso de novo, em vez de apagar um log em uso, esvazie: sudo truncate -s 0 /caminho/arquivo.log.

Evitar que o disco encha de novo

• Alerta quando o disco e os inodes passarem de 80% (veja monitorar a VPS 24 horas).
• Limite do journal no journald.conf e regra de logrotate para cada log de aplicação.
• Limite de log nos containers Docker.
• Backups enviados para fora da VPS, com retenção automática (veja backup com rsync).
• Rotina mensal com apt autoremove e limpeza de imagens antigas do Docker.

Quando limpar não basta

Se o disco volta a passar de 80% em poucas semanas, os dados estão crescendo de verdade: banco, uploads, mundos de jogo. A resposta é mais disco. Nas VPS da RoxyCloud, todas com NVMe, o disco cresce junto com o plano: por exemplo, a linha Xeon vai de 20 GB no plano de 2 GB a 300 GB no de 64 GB, e a Ryzen 9 vai de 35 GB a 250 GB. O upgrade é feito sem recontratar (veja upgrade e downgrade). Depois do upgrade, pode ser preciso expandir a partição e o sistema de arquivos; no Windows, siga como expandir o disco no Windows. Para grandes volumes de dados, compare os servidores dedicados.

Perguntas frequentes