Tem uma conversa que eu já tive vezes demais: "Bruno, o site sumiu/foi invadido — me ajuda a voltar do backup". Aí vem a pergunta que define tudo: "qual backup?". Quando a resposta é "o automático da hospedagem", a história costuma terminar mal. Esse guia é pra você nunca viver esse momento.
Por que o backup da hospedagem não basta
Não é que ele seja inútil — é que ele é uma cópia, e você não pode depender de uma só. Os motivos:
- Mora na mesma casa. Muitas vezes o backup fica na mesma máquina/datacenter do site. Se o servidor cair — ou for comprometido, como no caso do LiteSpeed que comentei ontem — o backup pode cair junto.
- Você não controla. Frequência, retenção e disponibilidade são decisão da hospedagem, não sua.
- Conta suspensa = backup perdido. Atraso no pagamento, violação de termos ou encerramento, e o backup vai embora com a conta.
Use o backup da hospedagem, sim — como uma das suas cópias. Não como a única.
A regra 3-2-1 (a base de tudo)
É o padrão que profissionais de TI usam há décadas, e cabe perfeitamente num site:
- 3 cópias dos seus dados (a original + 2 backups).
- 2 mídias/locais diferentes (ex.: o servidor + um armazenamento em nuvem).
- 1 cópia fora do site (off-site) — em outro provedor, fora do alcance do que derrubaria o servidor.
O que entra no backup (os dois pedaços)
Um site são duas coisas, e backup que esquece uma delas é inútil:
- Arquivos: o código, os uploads/mídia, temas, plugins e arquivos de configuração.
- Banco de dados: o conteúdo de verdade — posts, páginas, usuários, pedidos, configurações.
Arquivos sem banco = um site vazio. Banco sem arquivos = conteúdo sem o site. E atenção: versionar o código no Git não é backup — o Git guarda o código, mas não os uploads dos clientes nem o banco.
Como fazer na prática
WordPress: um plugin como UpdraftPlus ou All-in-One WP Migration, agendado e apontando para um destino externo (Google Drive, S3, Dropbox). Nada de salvar o backup na própria pasta do site.
Site sob medida (PHP e afins): uma tarefa agendada (cron) que empacota arquivos + banco e envia para fora. O esqueleto que eu uso:
# backup-diario.sh — arquivos + banco, enviados para um storage externo
DIA=$(date +%F)
mysqldump -u USER -pSENHA NOME_DO_BANCO | gzip > /tmp/db-$DIA.sql.gz
tar -czf /tmp/site-$DIA.tar.gz /caminho/do/site
# envia para fora da hospedagem (rclone -> Google Drive/S3/Backblaze)
rclone copy /tmp/db-$DIA.sql.gz remoto:backups/
rclone copy /tmp/site-$DIA.tar.gz remoto:backups/
rm -f /tmp/db-$DIA.sql.gz /tmp/site-$DIA.tar.gzAgende no cron (ex.: todo dia às 3h) e mantenha várias versões — não só a última. Se um problema (ou um ransomware) contaminar o site, a última cópia pode já estar estragada; você vai querer voltar a uma de dias atrás.
O passo que quase ninguém dá: testar a restauração
Esse é o pulo do gato. Backup que nunca foi restaurado é só esperança. Arquivos corrompidos, dump incompleto, exclusão que ninguém percebeu — você só descobre na hora H, que é exatamente a pior hora. A cada poucos meses, pegue o backup e restaure num ambiente de teste (local ou um subdomínio) e confirme que o site sobe inteiro. Se você nunca restaurou, você não tem um backup — tem um arquivo e um voto de fé.
Checklist do backup que salva
- ☐ É automático (não depende de você lembrar).
- ☐ Inclui arquivos + banco de dados.
- ☐ Pelo menos uma cópia fora da hospedagem.
- ☐ Guarda várias versões (não só a mais recente).
- ☐ A restauração foi testada nos últimos meses.
- ☐ As credenciais do destino de backup estão guardadas em local seguro.
Quero uma rotina de backup que realmente salva
Não tem certeza se o seu backup funcionaria na hora do aperto? Eu monto (e testo) uma rotina 3-2-1 pro seu site — bora conversar.