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/mysqlou/var/lib/mariadbwp-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/mysqlem volume próprio/backupem 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

