Backup é o tipo de coisa que todo mundo acha que tem até precisar dele. Disco corrompido, rm no diretório errado, ransomware ou um deploy que apagou dados: o que separa um susto de um desastre é ter uma cópia recente, completa e restaurável.
A regra 3-2-1 explicada
- 3 cópias dos dados (a original e mais duas).
- 2 mídias ou sistemas diferentes (por exemplo, disco do servidor e armazenamento externo).
- 1 cópia fora do local, em outro provedor ou região.
Um backup salvo no mesmo disco do servidor não é backup: se o disco falhar ou o servidor for comprometido, você perde os dois.
O que precisa entrar no backup de um VPS
| Item | Exemplos | Atenção |
|---|---|---|
| Bancos de dados | MySQL/MariaDB, PostgreSQL | Use dump consistente; nunca copie apenas os arquivos do banco em execução. |
| Arquivos das aplicações | /var/www, uploads, storage/ | Uploads de usuários não estão no Git. |
| Variáveis e segredos | .env, chaves de API | Guarde com criptografia. |
| Configurações do sistema | Nginx/Apache, PHP-FPM, cron, systemd | Sem elas, reconstruir o servidor leva horas. |
| Certificados | /etc/letsencrypt | Evita reemissão em massa e limites de taxa. |
Como gerar dumps consistentes
# MySQL / MariaDB (InnoDB) sem travar o banco
mysqldump --single-transaction --routines --triggers --all-databases | gzip > mysql-$(date +%F).sql.gz
# PostgreSQL
pg_dump -Fc -d meu_banco -f meu_banco-$(date +%F).dumpCom que frequência fazer backup?
Defina dois números para cada sistema:
- RPO (Recovery Point Objective): quantos dados você aceita perder. Um RPO de 1 hora exige backup de hora em hora.
- RTO (Recovery Time Objective): em quanto tempo o sistema precisa voltar ao ar.
| Tipo de sistema | Banco de dados | Arquivos | Retenção sugerida |
|---|---|---|---|
| E-commerce / SaaS | De hora em hora | Diário | 7 diários + 4 semanais + 3 mensais |
| Site institucional / blog | Diário | Semanal | 7 diários + 4 semanais |
| Homologação | Semanal | Semanal | 2 a 4 cópias |
O passo que quase todos esquecem: testar a restauração
Um backup que nunca foi restaurado é apenas uma suposição. Pelo menos uma vez por mês:
- Restaure o dump em um banco temporário e confira a contagem de registros das tabelas principais.
- Verifique se o arquivo compactado não está corrompido (
gzip -t arquivo.sql.gz). - Cronometre o processo: esse é o seu RTO real.
Como o EzServer automatiza isso
- Descoberta automática de aplicações e bancos em cada servidor, para que nada fique de fora por esquecimento.
- Backups agendados de arquivos e bancos, com verificação dos dumps.
- Política de retenção e limpeza de cópias antigas, evitando que o próprio backup encha o disco (um problema mais comum do que parece).
- Tudo em um painel, para vários servidores ao mesmo tempo.
Atenção a um erro clássico: backups gravados em
/tmp ou no mesmo disco, sem retenção, enchem o servidor e derrubam a aplicação. Sempre limite a quantidade de cópias locais.