Planejamento de crescimento de storage: como evitar disco cheio em produção

planejamento crescimento

O que é, de verdade, planejar crescimento de storage

planejamento de crescimento de storage. Não é “comprar mais disco”. É responder antes do problema:

  • Quanto cresce por mês?
  • O que cresce?
  • Quando vai estourar?
  • O que acontece quando estoura?
  • Qual é a ação automática / planejada?

Planejamento bom evita:

  • downtime silencioso
  • MySQL corrompendo tabela
  • PHP-FPM travando
  • backup falhando sem aviso

1️⃣ Saiba exatamente O QUE cresce

Antes de falar em GB, fale em tipo de dado:

Normalmente os vilões:

  • /var/lib/mysql ou /var/lib/mariadb
  • wp-content/uploads
  • logs (/var/log, logs do Nginx, PHP, app)
  • backups locais esquecidos
  • cache mal configurado
  • e-mails (Maildir explode fácil)

Comando rápido pra mapear:

du -xh / --max-depth=2 | sort -h

Depois aprofunde:

du -xh /var --max-depth=2 | sort -h

👉 Planejamento sem mapa é chute.


2️⃣ Meça crescimento real (não estimado)

O erro clássico: “acho que cresce pouco”.

Regra de ouro

📈 Use histórico, não feeling

Estratégia simples:

  • Capture uso diário ou semanal:
df -h / >> /var/log/storage-history.log

Ou melhor:

du -sh /var/lib/mysql >> /var/log/mysql-growth.log
du -sh /var/www >> /var/log/web-growth.log

Em 30 dias você já tem:

  • crescimento médio
  • picos
  • dias anômalos (ataque, bug, campanha)

3️⃣ Trabalhe sempre com margem (isso é obrigatório)

Nunca planeje para 100%.

Boas práticas:

  • Zona segura: até 70%
  • Zona de alerta: 70–80%
  • Zona crítica: >80%
  • Zona de desastre: 95%+

💣 Acima de 90%:

  • MySQL pode parar
  • journaling pode falhar
  • kernel pode travar I/O

👉 Planejamento sério considera 30% de folga.


4️⃣ Separe crescimento previsível vs imprevisível

Previsível:

  • uploads
  • banco de dados
  • logs rotacionáveis

Imprevisível:

  • ataques
  • loops de log
  • bug gerando arquivos
  • dump esquecido em produção

📌 Para o imprevisível, você precisa de:

  • alertas
  • quotas
  • rotação agressiva

5️⃣ Estratégias reais de crescimento

Opção A — Expandir disco

✔ simples
❌ downtime às vezes
❌ custo maior

Ideal se:

  • VPS/cloud
  • LVM ativo
  • crescimento linear

Opção B — Storage separado

Ex:

  • /var/lib/mysql em volume próprio
  • /backup em disco secundário

✔ isolamento
✔ menos risco sistêmico
❌ mais complexidade

👉 Muito recomendado em produção.


Opção C — Object Storage

Ideal para:

  • uploads
  • backups
  • mídia

✔ escalável
✔ barato
❌ latência
❌ não serve pra banco

Ex: S3, Backblaze, Wasabi.


6️⃣ Logs e backups: controle ou eles te controlam

Logs

  • logrotate agressivo
  • compressão
  • retenção curta em produção

Exemplo mental:

log é dado temporário, não histórico eterno


Backups

❌ Backup local sem limpeza = bomba-relógio
✔ retenção clara:

  • diário: 7 dias
  • semanal: 4
  • mensal: 3

E preferencialmente fora do servidor.


7️⃣ Alertas antes do desastre

Planejamento sem alerta é teoria.

Mínimo aceitável:

  • alerta em 70%
  • alerta em 80%
  • alerta crítico em 90%

Ferramentas:

  • Prometheus + Alertmanager
  • Zabbix
  • Netdata
  • até cron + Telegram serve

8️⃣ Pergunta que TODO planejamento deve responder

“Se amanhã dobrar o uso de disco, o que acontece?”

Se a resposta for:

  • “não sei”
  • “torcer pra não acontecer”
  • “ver depois”

👉 você não tem planejamento, só esperança.


Resumo brutalmente honesto

✔ Planejamento de storage é processo contínuo
✔ Crescimento sempre acontece
✔ Disco cheio quase nunca é surpresa — é negligência
✔ Quem mede, antecipa
✔ Quem não mede, apaga incêndio