De quanto espaço em disco um VPS precisa? Medimos o que realmente o enche

As páginas de planos destacam a RAM, mas um disco cheio derruba um servidor com a mesma certeza. Com "No space left on device", os bancos de dados param de gravar e os sites de responder, não importa quanta memória esteja livre. O uso do disco é fácil de prever quando você sabe o que cresce. Iniciamos servidores novos a partir das nossas próprias imagens e medimos cada um dos suspeitos de sempre.

O que um servidor recém-criado ocupa

Medido logo após o primeiro boot:

No Linux, quase todo um Nano de 15 GB é seu desde o primeiro dia. O Windows ocupa mais de um quarto dos seus 50 GB antes de você instalar qualquer coisa e, como verá abaixo, as atualizações levam mais.

Parte dos 2,7 GB do Ubuntu era fácil de recuperar. 440 MB eram o cache de pacotes das atualizações do primeiro boot, e havia três kernels instalados, embora só um seja usado. Dois comandos deixaram o ocupado em 2,16 GB:

sudo apt clean
sudo apt autoremove --purge

Docker: as imagens se acumulam rápido

Instalar o Docker em si acrescentou cerca de 300 MB. O que pesa são as imagens. Baixamos oito comuns, uma após a outra, e medimos a cada vez quanto o disco cresceu:

Imagens que compartilham uma base reaproveitam suas camadas, por isso python:3.12-slim acrescentou só 59 MB: nginx:latest e postgres:16 já tinham trazido a mesma base Debian. Imagens baseadas em Alpine são várias vezes menores que as completas. Só node:22 pesa 1,5 GB, então, quando puder, construa sobre node:22-slim ou node:22-alpine.

As imagens se empilham a cada atualização: cada docker compose pull deixa a versão antiga para trás. No nosso servidor de teste, um comando removeu todas:

docker system df
docker system prune -a

Ele informou 4,1 GB recuperados. prune -a apaga toda imagem que nenhum contêiner usa, então execute-o com seu stack no ar. Os volumes não são tocados, a menos que você acrescente --volumes.

Logs: o que enche um disco em uma noite

O Docker guarda tudo o que um contêiner imprime, e por padrão sem limite de tamanho. Rodamos um contêiner que imprimia uma linha curta em loop, o tipo de saída que um health check ou um modo de depuração produz. Depois de 30 segundos, seu arquivo de log tinha 6 MB. Nesse ritmo, escreveria cerca de 17 GB por dia, mais que o disco inteiro de um plano Micro.

Defina um limite para todos os contêineres novos em /etc/docker/daemon.json:

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

Depois execute sudo systemctl restart docker e recrie seus contêineres (docker compose up -d --force-recreate). Os contêineres existentes mantêm as configurações com que foram criados. Com o limite, o log do mesmo contêiner de teste tinha 4 MB após 30 segundos e nunca passará de 30 MB.

O journal do sistema já tem limite: no nosso servidor Ubuntu de 25 GB, o journald se limita a 2,3 GB, um décimo do sistema de arquivos. Estava usando 15 MB.

Windows: as atualizações precisam de espaço

Nossa imagem do Windows Server 2022 era de 2022, então a atualizamos. Enquanto a primeira atualização cumulativa era instalada, o ocupado subiu de 12,6 para 20,8 GB e, após a segunda, chegou a 24,5 GB. O Windows guarda a versão antiga de cada arquivo de sistema que uma atualização substitui. A limpeza o trouxe de volta a 14,6 GB, e um servidor novo criado a partir da imagem atualizada agora começa em 14 GB. Mantenha pelo menos 10 GB livres para a próxima atualização. O guia de atualizações do Windows traz os comandos de limpeza.

O que escolher

Duas regras fazem qualquer um deles durar mais: limite os logs dos contêineres antes do deploy e copie os backups para fora do servidor em vez de mantê-los no disco dele. Se um servidor já está cheio, nosso guia para liberar espaço em disco mostra o passo a passo. Para o lado da memória no dimensionamento, veja de quanta RAM um VPS precisa. Todos os planos estão na página VPS, com pagamento em USDT, USDC ou ETH nas redes Base, Ethereum ou Polygon.