Construindo Uma Estratégia De Backup Com Snapshots Usando Borg, Rclone E Google Drive
Se você administra seus próprios serviços (self-hosting), já deve ter aprendido a regra de ouro da sobrevivência digital da pior maneira possível: quem tem um backup não tem nenhum; quem tem dois tem um. Quando falamos de dados ultra-sensíveis, como as senhas do Vaultwarden, o gerenciador de crises precisa ser implacável. Não dá para confiar em um script tar -czf jogado no cron do servidor que você nem sabe se rodou ontem.
Neste artigo, vou destrinchar a arquitetura de uma solução de backup automatizada, segura e eficiente que desenvolvi. Ela utiliza BorgBackup, Borgmatic, Rclone e Supercronic, tudo encapsulado elegantemente no Docker.
Por que escolhi esta Stack?
Montar uma estratégia de backup não é apenas escolher ferramentas famosas, mas sim entender como elas se complementam. Veja o porquê de cada componente estar aqui:
BorgBackup vs Tar/Zip Tradicional
Se você faz backup diário de um volume de dados, gerar um arquivo .tar.gz todo dia vai devorar o seu armazenamento. O Borg foi escolhido por três motivos cruciais:
- Deduplicação baseada em blocos: Ele analisa os arquivos e só armazena o que mudou a nível de bloco. Se o seu banco de dados mudou 2MB de ontem para hoje, o backup ocupará apenas 2MB, não o tamanho total do banco.
- Criptografia nativa: Os dados são criptografados no cliente (client-side encryption) antes de saírem do container. Nem o Google Drive sabe o que tem lá dentro.
- Velocidade e compressão: É incrivelmente veloz e flexível nas políticas de compressão.
Borgmatic vs Scripts Shell Puros
Escrever scripts em Bash para gerenciar chaves do Borg, criar arquivos e limpar snapshots antigos é um convite ao desastre. O Borgmatic atua como uma camada de orquestração declarativa. Você define o que quer em um arquivo YAML legível (config.yaml), e ele cuida do trabalho sujo de validação, expurgo (pruning) e ganchos (hooks) de pós-execução.
Rclone
O Borg é excelente para backups locais ou via SSH, mas ele não conversa nativamente com storages de objetos ou Google Drive. O Rclone resolve isso perfeitamente. Ele pega o repositório local do Borg (já criptografado e deduplicado) e o espelha de forma eficiente na nuvem.
Supercronic vs Cron
O cron tradicional do sistema operacional costuma falhar silenciosamente dentro de containers Docker, além de lidar mal com variáveis de ambiente e não encaminhar os logs para o stdout. O Supercronic é um executor de tarefas feito sob medida para containers: respeita as variáveis do Compose e entrega logs limpos. Assim que parei de tentar usá-lo e fui para o Supercronic, foi como sair da água suja para o vinho.
A lógica por trás desta arquitetura
A imagem mental do projeto é simples:
[Volume Vaultwarden]
│ (Somente Leitura)
▼
[Container Docker: Borgmatic] ──► [Volume Local: Borg Repo]
│
│ (Rclone Sync)
▼
[Google Drive Remoto]Por que não enviar direto para a nuvem sem repositório local?
Se o seu servidor cair, baixar 50GB da nuvem para começar a recuperar o serviço custa tempo e banda. Mantendo o repositório Borg em um volume local, a restauração é instantânea. O envio para o Google Drive cumpre estritamente a cota de “Disaster Recovery” (recuperação de desastres fora do ambiente principal).
Por que fiz a escolha de não usar ferramentas como Duplicati ou Restic?
A escolha da ferramenta ideal de backup exige um equilíbrio entre estabilidade, eficiência e controle. Abaixo, detalho os motivos que me levaram a descartar o Duplicati e a preferir o ecossistema Borg em detrimento do excelente Restic.
O problema com o Duplicati
O Duplicati possui uma interface gráfica fantástica e muito amigável. No entanto, sua engine baseada em um banco de dados SQLite local apresenta um gargalo estrutural crítico: ela costuma corromper quando lida com grandes volumes de dados sob uso intenso, comprometendo a confiabilidade que um sistema de backup exige.
Restic vs BorgBackup
O Restic é uma ferramenta robusta e concorre diretamente com o Borg. Ambos oferecem criptografia, deduplicação e suporte a diversos backends (como SSH, S3, rclone e nuvem). Porém, ao analisarmos as características técnicas e arquiteturais de cada um, as vantagens do Borg se alinharam melhor às necessidades do projeto.
Aqui está o comparativo detalhado que embasou a decisão:
1. Modelos de Backup e Execução
- Borg: Segue um modelo estritamente focado em armazenar apenas as mudanças desde o último backup. Isso resulta em execuções mais rápidas e arquivos de backup consideravelmente menores.
- Restic: Adota um modelo onde cada execução representa um instantâneo (snapshot) completo dos dados. Embora permita incrementais (não sendo o comportamento padrão), sua abordagem foca mais na resiliência contra corrupções do que no tamanho do arquivo.
2. Deduplicação e Compressão (Eficiência de Armazenamento)
- Borg: Utiliza algoritmos como o lz4 aplicados diretamente dentro dos repositórios de backup. Essa abordagem é agressiva na maximização da eficiência do armazenamento, economizando espaço em disco.
- Restic: Emprega o Zlib para otimizar o armazenamento em repositórios compartilhados. Foca em entregar um bom desempenho e facilitar o gerenciamento do repositório, mas consome um pouco mais de espaço em comparação ao Borg.
3. Desempenho e Consumo de Recursos
- Borg: É mais focado no uso eficiente da CPU. Por conta de sua arquitetura de processamento, ele costuma ser superior e mais rápido na manipulação de backups de maior volume.
- Restic: É otimizado para manter um baixo uso de memória RAM e possui um recurso de cache inteligente para dados muito acessados. Geralmente, apresenta maior velocidade em backups menores.
4. Segurança e Criptografia
Ambos empatam em excelência neste quesito. O Restic utiliza encriptação forte AES-256, enquanto o Borg utiliza criptografia autenticada nativa. Nenhum dos dois deixa a desejar na proteção dos dados em trânsito ou em repouso.
Como o Borg foi escolhido em definitivo?
Maturidade e Controle com Borgmatic
Embora o Restic ofereça maior flexibilidade de agendamento e resiliência contra corrupção em snapshots, o Borg se mostrou a solução definitiva quando somado ao Borgmatic.
Para o cenário de servidores enxutos, o conjunto Borg + Borgmatic entrega um controle de retenção (pruning) extremamente maduro, além de possuir ganchos nativos para envio de notificações por e-mail e execução de rotinas pré e pós-backup (como dumps de banco de dados). A união da eficiência de armazenamento do Borg (arquivos menores e mais rápidos em grandes volumes) com a orquestração do Borgmatic superou a concorrência.
Escalabilidade e Visão de Futuro
Essa escolha se torna ainda mais estratégica pensando no futuro do ambiente. No momento, a estrutura atende especificamente ao armazenamento seguro dos dados do Vaultwarden, mas o projeto foi desenhado para propósitos gerais. Em breve, ele servirá como o gerenciador central de backup de diversas outras aplicações que pretendo implementar.
Eficiência de Custos na Nuvem
Por fim, há um forte fator econômico envolvido: como o destino final desses dados é a nuvem, o espaço em disco dita o valor da fatura. A compressão superior do Borg gera arquivos significativamente menores, otimizando o tráfego e reduzindo os custos de hospedagem. Para um cenário non-enterprise (doméstico ou de pequenos projetos), onde cada centavo conta, minimizar o custo de armazenamento sem perder segurança é o objetivo principal.
O Fator Host Windows: A Irrelevância de Btrfs ou ZFS
Outro ponto determinante para consolidar essa arquitetura é o fato de o host ser Windows.
Em um sistema operacional que opera nativamente sobre NTFS (ou ReFS), discussões sobre as vantagens estruturais de sistemas de arquivos como Btrfs ou ZFS perdem o sentido prático. Como o Windows não oferece suporte nativo a essas tecnologias, recursos como snapshots de sistema de arquivos ou deduplicação ao nível do sistema operacional (OS-level) estão fora de questão na origem.
Isso significa que, independentemente de como um gerenciador de backup lide com Btrfs ou ZFS em ambientes Unix, no cenário Windows a inteligência de deduplicação, compactação e segurança obrigatoriamente precisa acontecer no nível da aplicação.
Dessa forma, a escolha por uma ferramenta com uma engine interna de gerenciamento de dados altamente eficiente e independente do sistema de arquivos subjacente — como o Borg (operando via WSL/Docker no Windows) — garante que o ecossistema de destino seja otimizado, sem depender de recursos que o host Windows simplesmente não pode fornecer.
Anatomia do Projeto: Estrutura de Arquivos
O projeto está organizado para ser modular e reprodutível:
.
├── Dockerfile # Imagem personalizada
├── compose.yml # Orquestração do serviço e volumes
├── .env # Variáveis sensíveis (Senhas e SMTP)
├── config.yaml # Configurações Borgmatic
├── config/
│ ├── logrotate.conf # Gerenciamento de espaço dos logs
│ └── supercronic.conf # Agendamento das tarefas (Cron)
├── rclone_config/ # Credenciais do Google Drive
├── borg-keys/ # Chaves de criptografia exportadas para serem guardadas
└── scripts/ # Automações de boot e execuçãoComponentes em Destaque
O Arquivo de Configuração do Borgmatic (config.yaml)
Desempenho e Operação
compression: lzma: Define o algoritmo de compressão utilizado pelo Borg. Olzmaoferece uma taxa de compressão extremamente alta, sendo ideal para economizar espaço em disco, embora demande um pouco mais de CPU durante o backup.verbosity: 1: Controla o nível de detalhamento dos logs no console. O nível1(normal) equilibra informações suficientes para monitorar o progresso sem inundar os logs com dados de depuração desnecessários.source_directories: Indica ao Borgmatic quais volumes devem ser protegidos. Aqui, estamos focando estritamente no volume de dados do Vaultwarden.archive_name_format: Define o padrão de nomenclatura dos snapshots:"{hostname}-{now:%Y-%m-%dT%H:%M:%S}". Utiliza o formato ISO 8601, que é ordenável alfabeticamente e facilita a identificação temporal exata de cada backup.
Política de Retenção (Ciclo de Vida)
O Borgmatic gerencia automaticamente a exclusão de backups antigos (pruning) para evitar que o disco fique cheio, seguindo as diretrizes de retenção GFS (Grandfather-Father-Son):
keep_daily: 7: Mantém os 7 backups diários mais recentes.keep_weekly: 4: Mantém um snapshot por semana, durante as últimas 4 semanas.keep_monthly: 6: Mantém um snapshot por mês, durante os últimos 6 meses.
Nota: O Borgmatic seleciona automaticamente quais arquivos apagar para cumprir essas metas, garantindo que você nunca perca o histórico de longo prazo.
Integridade e Verificações
checks: A rotina de saúde do repositório:repository: Verifica a consistência da estrutura do banco de dados do Borg.archives (frequency: 2 weeks): Valida a integridade dos arquivos armazenados. Esta verificação ocorre quinzenalmente para detectar qualquer corrupção silenciosa nos dados armazenados.
Notificações via Apprise
O Apprise permite o envio de alertas para diversos serviços. Quando digo diversos, não estou mentindo: há dezenas deles listados no site oficial (Appriseit.com). Inclusive, nas próximas modificações, pretendo adicionar integrações extras neste projeto, como o NTFY ou o Telegram.
- Configuração: O sistema está configurado para disparar notificações nos estados
finish(sucesso) efail(falha). - Logs:
send_logs: truegarante que o resumo da execução do backup seja enviado diretamente no corpo do e-mail, permitindo diagnósticos rápidos em caso de falha. - Alerta via E-mail: Utiliza o protocolo
mailtosintegrado ao Gmail via SMTP.
Dica: Certifique-se de que as variáveis de ambiente
SMTP_USER,SMTP_PASS,SMTP_PORTeSMTP_TOestejam corretamente definidas no seu arquivo.env.
Automação de Sincronização (Cloud Hook)
commands: Define ações automatizadas pós-execução.- **Hook
- after: repository**: Esta diretriz garante que, somente após a conclusão bem-sucedida do backup (estadofinish), o comando de sincronização a seguir será executado. rclone sync: Espelha o repositório Borg local (deduplicado e criptografado) para o remotogcp-storage. O uso dosyncassegura que o remoto seja um reflexo fiel do estado atual do seu volume local, mantendo a nuvem sempre atualizada sem duplicar dados desnecessários.
Este nível de configuração garante que o seu backup não apenas “aconteça”, mas seja monitorado e auditado de maneira simples.
Executando (Instalação e Uso)
Preparando o ambiente
Edite o nome do arquivo examples.env para .env na raiz do projeto e insira as suas credenciais:
SMTP_USER=user@gmail.com
SMTP_PASS=aaaabbbbccccdddd
SMTP_PORT=587
SMTP_TO=your_email@gmail.com
BORG_PASSPHRASE=<sua_senha>Escolhendo entre Docker Compose e Docker Exec
Ao interagir com o seu container de backup, a escolha do comando altera o contexto de execução:
docker compose exec borg-backup <comando>: Use esta opção quando estiver no diretório raiz do projeto. É a abordagem mais segura, pois utiliza o nome do serviço definido no seucompose.yml, abstraindo o nome real do container (ex:backup-solution-borg-backup-1) e garantindo que você está dentro do contexto correto.docker exec -it <nome_do_container> <comando>: Use esta opção se estiver em outro diretório ou se precisar rodar um comando rápido sem depender da estrutura do projeto. É a forma mais direta de acessar qualquer container pelo nome atribuído no Docker Engine.
Autenticando o Google Drive (Rclone)
A melhor prática para não expor navegadores dentro do servidor é configurar o Rclone na sua máquina local e apenas mover o arquivo gerado. Caso faça isso, pule para a seção Subindo o Serviço.
Se precisar testar ou reautorizar direto pelo container, use:
docker compose run --rm debian_container rclone config reconnect gcp-storage: --config /root/.config/rclone/rclone.confPara garantir que o container está enxergando a nuvem corretamente, liste os diretórios remotos:
docker compose run --rm debian_container rclone lsd gcp-storage: --config /root/.config/rclone/rclone.confSubindo o Serviço
Pronto? Agora basta fazer o build e inicializar o container em modo detached:
docker compose up -d --buildNo primeiro início, o script scripts/bootstrap.sh vai detectar que o repositório Borg não existe, irá inicializá-lo usando a sua BORG_PASSPHRASE e fará o backup emergencial das chaves criptográficas para a pasta ./borg-keys. Guarde essas chaves fora do servidor! Se o servidor queimar e você perder essas chaves, o backup na nuvem se tornará apenas ruído criptográfico inútil.
Operação e Manutenção Diária
Como rodar um backup manual agora?
Não quer esperar pelo agendador? Dispare o script diretamente:
docker compose exec borg-backup /bin/sh -c '/scripts/backup.sh'Verificando a Saúde e os Logs
Os logs não somem no éter. Eles passam por uma rotação mensal via logrotate para não estourar o armazenamento do host. Para ver as últimas linhas do log atual:
docker compose exec borg-backup tail -n 50 /var/log/borg/borg-backup.logO Pior Aconteceu: Como Restaurar o Backup?
Backup só é backup se a restauração funciona. Caso precise recuperar o Vaultwarden, siga estes passos:
Primeiro Passo: Puxe o repositório da nuvem para um local temporário
Caso tenha perdido tudo localmente, é necessário baixar os arquivos da nuvem executando o comando abaixo. Caso contrário, pule para o Segundo Passo.
docker compose exec borg-backup rclone sync gcp-storage:BACKUP-VOLUMES /tmp/backup-local-borg --config /root/.config/rclone/rclone.conf -vSegundo Passo: Liste os arquivos disponíveis
Se você pulou o primeiro passo, é porque já tem os dados no volume local. Nesse caso, substitua /tmp por /volumes nos comandos.
docker compose exec borg-backup borg repo-list -r /tmp/backup-local-borg -vIsso retornará uma lista de snapshots com marcações de data e hora. Se não retornar os snapshots esperados, baixe-os da nuvem e repita o processo. Você pode visualizar detalhes do repositório original em: /var/log/borg/borg-backup.log.
Terceiro Passo: Verifique a integridade
Antes da restauração, é recomendável verificar a integridade dos seus arquivos usando o comando abaixo (novamente, substitua /tmp/backup-local-borg por /volumes/backup-local-borg se estiver restaurando diretamente do volume local):
docker compose exec borg-backup borg check --repo /tmp/backup-local-borg/ --verify-data -vQuarto Passo: Extraia o snapshot desejado
Substitua Debian-2026-06-07T00:24:03 pelo nome do snapshot retornado no passo 2:
docker compose exec borg-backup sh -c "cd / && borg extract -r /tmp/backup-local-borg Debian-2026-06-07T00:24:03 /volumes/vaultwarden-data"Após subir o container do Vaultwarden com as variáveis de ambiente devidamente configuradas, o estado dos dados será exatamente aquele contido no snapshot escolhido para a restauração.
Fontes e Referências utilizadas: