Ninguém pensa em backup até a hora que precisa. Nessa hora, ou tem — e você respira aliviado — ou não tem — e você reconstrói meses de trabalho no braço. Este post é pra quem quer estar do lado certo dessa história.
E o pior: a maioria das empresas que "tem backup" descobre no momento do desastre que o backup não funciona. Nunca testaram. Nunca conseguiram restaurar. Backup mal-feito é pior que não ter — cria falsa sensação de segurança.
Cenários reais que fazem você querer backup
- Hospedagem sofre ataque de ransomware — arquivos criptografados exigindo resgate
- Update automático de plugin/módulo quebra o site
- Funcionário apaga banco de dados sem querer
- Ex-funcionário deleta dados por vingança
- HD do servidor falha (não é raro — falha silenciosa acontece a toda hora)
- Conta na hospedagem suspensa por atraso — todos os arquivos são deletados após X dias
- Hacker invade e injeta código malicioso — precisa voltar pra versão limpa anterior
- Migração pra nova hospedagem dá errado no meio
A regra 3-2-1 (padrão da indústria)
Regra clássica de backup:
- 3 cópias dos dados (original + 2 backups)
- 2 mídias diferentes (ex: servidor + cloud)
- 1 cópia offsite (fora da mesma infra do original)
Por quê? Se a cópia original E o backup principal estão no mesmo servidor, um incidente pode destruir os dois. Se estão no mesmo prédio, um incêndio destrói ambos. A cópia offsite é o seu seguro contra o pior cenário.
O que precisa entrar em backup
- Banco de dados — MySQL, PostgreSQL etc. Dump completo, com estrutura + dados. Formato SQL ou binário nativo.
- Arquivos do sistema — código PHP/JS, imagens uploadadas por clientes, PDFs gerados, tudo em /public_html ou equivalente.
- Arquivos de configuração — .env, secrets, credenciais criptografadas. Cuidado extra pra não vazar — mas precisa ter no backup ou não consegue restaurar.
- E-mails — se você usa e-mail no cPanel/hospedagem, tem que ter dump das caixas. IMAP local nem sempre resolve.
- Certificados SSL (se auto-gerado — Let's Encrypt renova, ok. Se pago, guarda o .pem)
- Estrutura de DNS — não é backup técnico, mas anota em algum lugar. Se hospedagem trocou, precisa reconstruir.
Frequência
Depende de "quanto de perda de dados você aguenta". Se seu site recebe 1 pedido por dia, backup diário é suficiente — perde no máximo 1 dia. Se você recebe 100 pedidos por dia, backup diário é péssimo — perde 100 pedidos.
Frequência típica:
- Banco de dados: diário no mínimo. Site transacional (loja, sistema): a cada 4-6 horas. Alto volume: contínuo (replicação em tempo real).
- Arquivos: semanal se muda pouco (site institucional). Diário se cliente faz upload todo dia (loja com imagens de produtos, sistema com PDFs).
- Full snapshot (imagem completa do servidor): semanal ou quinzenal.
Ferramentas por tipo de projeto
WordPress
- UpdraftPlus (grátis + pago): backup pra Google Drive, Dropbox, S3, FTP externo. Simples, funciona.
- Duplicator: bom pra migração + backup pontual.
- Jetpack Backup: pago da Automattic, contínuo, restauração em 1 clique.
Site PHP puro / feito à mão
- Script cron com
mysqldump | gzip | curlpra S3, Backblaze B2, Wasabi. Custo real: R$ 5-30/mês por site. - Rsync pra servidor secundário se você tem infra própria.
Hospedagem compartilhada (cPanel)
- cPanel tem "Full Account Backup" — bom pra backup completo mensal. Não conta como sua única estratégia (fica no mesmo servidor).
- JetBackup: extensão comum em cPanel, permite agendar externos.
Sistema em VPS / cloud
- Snapshots do provedor (DigitalOcean, Vultr, AWS EBS): rápido, mas fica no mesmo provedor. Não é offsite real.
- Restic ou BorgBackup: open-source, encrypted, incremental. Pra S3/Backblaze/etc.
- rclone: ótimo pra sync direto pra Google Drive, OneDrive, S3.
O teste que ninguém faz
Toda estratégia de backup precisa de teste de restore. Sem isso, é fé. Passos:
- Pega o backup mais recente
- Sobe num ambiente separado (subdomínio de teste, container local, VPS descartável)
- Restaura banco + arquivos
- Verifica: sistema abre? Login funciona? Dados dos últimos dias estão lá?
- Registra tempo total de restauração (isso é o "RTO" — Recovery Time Objective)
Fazer isso a cada 3 meses. Se descobrir problema, ainda dá tempo de arrumar. Se descobrir no dia do desastre, já era.
Erros clássicos
- Backup no mesmo servidor — servidor caiu, backup foi junto
- Backup no Google Drive pessoal do dono — sai da empresa, perde tudo
- Backup manual mensal — vai ficar meses sem fazer no dia que precisar
- Backup sem log — não sabe se rodou, só descobre quando abre e tá vazio
- Backup gigante nunca restaurado — arquivo corrompido, dependência quebrada, versão de banco incompatível
- Backup sem criptografia — se vaza, o atacante tem tudo em bandeja
- Não guardar backup antigo — descobriu invasão hoje mas ela começou há 2 meses. Backup de ontem já tá contaminado. Precisa ter backup de 60+ dias atrás.
Retenção sugerida
Estratégia comum:
- Últimos 7 dias completos
- 4 semanas (1 por semana)
- 12 meses (1 por mês)
- 2-3 anos (1 por trimestre) — pra conformidade fiscal/LGPD
Custo real
Backup em Backblaze B2 custa US$ 6/mês por TB. Site típico tem 5-20 GB, o que dá centavos por mês. Não fazer backup por custo é uma das piores decisões possíveis — o incidente vai custar 100x-10.000x mais.
Como a Uma Nova Imagem ajuda
- Auditoria de backup atual (grátis): olhamos o que você tem, se roda, se restaura. Damos parecer com pontos frágeis.
- Setup de estratégia 3-2-1 (a partir de R$ 800 setup + custo mensal do storage): configuração + monitoramento + teste inicial de restore.
- Contrato de gestão de backup (a partir de R$ 250/mês): monitoramos diariamente, testamos restore a cada 3 meses, avisamos se algo der errado antes de você descobrir sozinho.
Backup é seguro. Ninguém liga pra seguro até precisar dele. Mas quem precisou uma vez sabe: é a decisão de investimento com melhor ROI da empresa. Perder tudo custa muito mais que se prevenir.
