estratégia de backup para servidores Linux. backup de verdade em Linux não é “rodar rsync e rezar”. É estratégia + teste + automação. Vamos ao que funciona no mundo real, não no papel.
Estratégias de backup são fundamentais para garantir a recuperação de dados em caso de falhas ou incidentes. No entanto, quando backups começam a falhar ou ficam mais lentos que o esperado, é necessário investigar o comportamento do servidor. Para isso, ferramentas de análise do sistema são essenciais. Veja também o guia sobre ferramentas de diagnóstico no Linux.
O que NÃO é estratégia de backup (clássicos erros)
❌ Backup só no mesmo servidor
❌ Snapshot sem cópia externa
❌ Dump diário sem testar restore
❌ Backup sem versionamento
❌ “Meu provedor já faz backup”
Se qualquer um desses é sua única linha de defesa, você não tem backup.
Princípios de uma estratégia real
Guarde isso como regra de ouro:
Regra 3-2-1 (ainda imbatível)
- 3 cópias dos dados
- 2 tipos de mídia diferentes
- 1 cópia fora do servidor / datacenter
Camadas de backup (modelo profissional)
1️⃣ Snapshot local (rápido, NÃO é backup final)
Serve para erro humano e rollback rápido.
- LVM snapshot
- ZFS snapshot
- Btrfs snapshot
- Snapshot do hypervisor (Proxmox, VMware)
⚠️ Snapshot não protege contra:
- Ransomware
- Falha de disco
- Falha do host
Use como primeira camada, não como backup real.
2️⃣ Backup de arquivos (versionado)
Aqui é onde o backup começa a valer.
Ferramentas recomendadas
- BorgBackup ⭐⭐⭐⭐⭐
- Restic
- Duplicacy
Por quê?
- Deduplicação
- Compressão
- Criptografia
- Versionamento
- Restore rápido
Exemplo (Borg):
borg create --stats /backup::srv-{now} /etc /var/www /home
💡 Ideal para:
/etc/var/www- uploads
- arquivos de usuários
3️⃣ Backup de banco de dados (SEMPRE separado)
Nunca confie só em backup de arquivos para banco.
MySQL / MariaDB
mysqldump --single-transaction --routines --events --all-databases | gzip > db.sql.gz
Ou melhor:
mariabackup/xtrabackup(produção)
💡 Estratégia real:
- Dump lógico diário
- Backup físico semanal (se DB grande)
4️⃣ Cópia externa (offsite)
Sem isso, tudo acima é frágil.
Opções reais:
- Outro servidor (rsync + SSH)
- Object Storage (S3, Wasabi, Backblaze)
- NAS em outro local
Exemplo com Borg + SSH:
borg create user@backup:/repo::srv-{now} /data
🔐 Sempre criptografado.
Processos de backup podem gerar alta utilização de disco, CPU e rede, principalmente em ambientes com grandes volumes de dados. Monitorar esses recursos ajuda a evitar impacto em aplicações em produção. Para isso, é importante utilizar ferramentas de diagnóstico de servidores Linux que permitam analisar o comportamento do sistema durante essas operações.
Frequência que funciona na prática
Nada exagerado, nada insuficiente.
| Tipo | Frequência |
|---|---|
| Snapshot | Hora em hora |
| Backup arquivos | Diário |
| Backup DB | Diário |
| Backup offsite | Diário |
| Retenção curta | 7 dias |
| Retenção média | 30 dias |
| Retenção longa | 3–6 meses |
Automação (obrigatório)
Backup manual não existe.
- systemd timer ou
- cron ou
- ferramenta com scheduler próprio
Exemplo cron:
0 2 * * * /usr/local/bin/backup.sh
Teste de restore (onde todo mundo falha)
Backup não testado = backup inexistente.
Checklist mínimo mensal
- Restaurar 1 arquivo aleatório
- Restaurar 1 dump de banco
- Verificar integridade
- Medir tempo de restore
Se você nunca fez restore, assuma que está quebrado.
Monitoramento
Backup que falha em silêncio é armadilha.
Use pelo menos um:
- Email de sucesso/falha
- Healthchecks.io
- Zabbix / Prometheus
Exemplo de stack REAL (funciona muito bem)
Para servidores Linux / WordPress / VPS:
- Snapshot LVM (hora em hora)
- BorgBackup (diário)
- Dump MariaDB diário
- Cópia Borg via SSH para outro servidor
- Retenção automática
- Teste mensal de restore
Simples, barato, confiável.
Verdades duras (mas úteis)
- RAID não é backup
- Snapshot não é backup
- Backup do provedor não é seu backup
- Sem restore testado não existe backup
Uma estratégia de backup eficiente depende não apenas de ferramentas de armazenamento, mas também de monitoramento e análise do ambiente. Identificar gargalos de disco, CPU ou rede durante backups é essencial para manter a estabilidade do servidor. Para aprofundar esse tema, veja também o guia sobre principais ferramentas de diagnóstico em servidores Linux.
FAQ
Não. Snapshots ajudam em rollback rápido, mas não protegem contra falha de disco, ransomware ou perda total do servidor. Eles devem ser apenas uma camada complementar.
Não. RAID apenas aumenta disponibilidade e tolerância a falhas de disco, mas não protege contra exclusão acidental, corrupção de dados ou ataques.
BorgBackup é uma das melhores opções por oferecer deduplicação, compressão, criptografia e versionamento, sendo ideal para servidores Linux em produção.
O ideal é snapshot horário, backup diário de arquivos e bancos de dados, com pelo menos uma cópia offsite também diária.
Não. Backups do provedor não substituem uma estratégia própria, pois você não controla retenção, restore nem criptografia.
A única forma é testando o restore. Backups que nunca foram restaurados devem ser considerados não confiáveis.
Veja Mais:
Ferramentas de Diagnóstico Linux: Guia Definitivo de Performance (2026)
Servidor congela sem logs claros: causas reais e como diagnosticar
EXT4 vs XFS: Qual é o melhor filesystem para produção Linux?
Rede ok, mas site lento: onde está o gargalo?