Backup Incremental Linux. Para um administrador de servidores focado em produção e otimização, a escolha entre BorgBackup e Restic para destinos como S3 ou Wasabi depende de uma decisão técnica fundamental: simplicidade nativa vs. controle total de recursos.
Ambos são ferramentas de backup de “deduplicação em blocos” (chunking), o que significa que eles não apenas fazem backup incremental de arquivos novos, mas detectam mudanças dentro dos arquivos, economizando espaço massivo em bancos de dados ou logs.
1. Comparativo Estratégico
| Recurso | Restic | BorgBackup |
| Suporte Cloud (S3/Wasabi) | Nativo. Extremamente simples de configurar. | Requer Rclone ou SSH. Não fala S3 nativamente. |
| Uso de RAM | Alto. Pode ser um problema em VPS com < 2GB RAM. | Baixo/Otimizado. Muito mais estável em recursos limitados. |
| Compressão | Sim (Zstd), mas Borg é historicamente superior aqui. | Excelente. Múltiplos algoritmos (lz4, zstd, lzma). |
| Performance Remote | Rápido para envio, lento para prune (limpeza). | Rápido em tudo, mas complexo sobre S3. |
| Montagem FUSE | Sim (restic mount). | Sim (borg mount). |
2. Estratégia com Restic (A escolha “Cloud-Native”)
O Restic é a recomendação padrão para S3/Wasabi porque ele trata o bucket como um repositório comum.
Fluxo de Configuração (Wasabi/S3)
- Defina as variáveis no seu script:
export AWS_ACCESS_KEY_ID="seu_id" export AWS_SECRET_ACCESS_KEY="sua_chave" export RESTIC_REPOSITORY="s3:https://s3.wasabisys.com/nome-do-bucket" export RESTIC_PASSWORD="senha-criptografia" - Inicialize e execute:
restic init restic backup /var/www /etc /home - Poda (Prune): Como o Restic não roda “server-side” no S3, a limpeza de backups antigos pode ser lenta e consumir banda, pois ele precisa baixar índices para processar o que deletar.
3. Estratégia com BorgBackup (A escolha “Performance/SysAdmin”)
O Borg foi desenhado para arquiteturas Cliente/Servidor (via SSH). Para usar S3/Wasabi, você tem dois caminhos:
Opção A: Borg + Rclone (Mount)
Você monta o bucket S3 como um disco local usando rclone mount e aponta o Borg para lá.
- Vantagem: Usa a compressão superior do Borg.
- Risco: Se a conexão de rede oscilar durante o
mount, o banco de dados do Borg (chunks) pode corromper. Não recomendado para produção crítica.
Opção B: Borg + Repositório Dedicado (BorgBase/Rsync.net)
Em vez de S3 “puro”, usa-se um storage que aceite SSH. O Borg roda um binário no destino, tornando o prune e a deduplicação instantâneos.
4. Estratégia de Retenção (Geral)
Para manter o bucket limpo e os custos previsíveis no Wasabi (que tem retenção mínima de 90 dias em alguns planos), use uma política de Keep:
- Restic:
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune - Borg:
borg prune -v --keep-daily 7 --keep-weekly 4 --keep-monthly 6
FAQ
O Restic possui suporte nativo para nuvem (S3/Wasabi), enquanto o Borg exige SSH ou Rclone. No entanto, o Borg tende a ser mais eficiente no uso de memória RAM em servidores menores.
É uma técnica que identifica blocos de dados duplicados e armazena apenas uma cópia única, economizando até 80% de espaço em backups de bancos de dados e logs.
Sim, o Wasabi é ideal por não cobrar taxas de egresso (download) e ser compatível com a API S3, tornando o custo previsível para ferramentas como Restic.
Tanto o Borg quanto o Restic possuem comandos de integridade (check). É essencial rodar essa verificação via Cron semanalmente para validar os hashes dos dados.
Veja Mais:
Como fazer Backup Incremental Rsync Rclone sem travar o servidor
Como atualizar o Kernel do CentOS 7 / 8
Restaurando MySQL usando o MySQL Workbench
Backup de todos os bancos de dados mysql em um servidor Linux
Dispositivos de Armazenamento Secundário: Definição, Tipos e Casos de Uso em Backup