Restic e Borg: VPS para backups seguros

Resposta direta

Uma VPS para backups com Restic e Borg funciona bem quando é tratada como um cofre remoto: acesso SSH restrito, disco dimensionado pela retenção, criptografia ativa, automação por cron ou systemd timer e testes periódicos de restauração. Para projetos pequenos, 1 vCPU, 1 GB de RAM e 80 a 160 GB de SSD podem bastar. Para vários servidores, bancos de dados e retenção de 30 a 90 dias, pense em 2 a 4 vCPUs, 4 GB de RAM e 500 GB ou mais de armazenamento. Restic tende a ser mais simples para múltiplos backends e uso em S3. Borg é muito eficiente em deduplicação e compressão via SSH. Em ambos os casos, snapshot não substitui backup, mas ajuda na recuperação rápida quando usado junto de uma política remota.

Resumo rápido

• Restic e Borg fazem backup criptografado, deduplicado e incremental, mas têm fluxos diferentes de operação.
• A VPS de backup deve ficar separada do servidor de produção, com usuário restrito e acesso por chave SSH.
• Para produção pequena, comece com 2 vCPUs, 2 GB de RAM e disco pelo menos 3 vezes maior que o volume útil protegido.
• Retenção precisa ser planejada antes da compra: 7 diários, 4 semanais e 6 mensais mudam muito o consumo de disco.
• Teste de restauração é parte do backup. Sem restore testado, você só tem uma promessa.
• Snapshots ajudam em rollback rápido, mas não protegem contra exclusão acidental, invasão com credenciais válidas ou erro lógico replicado.
• Para acesso simples de clientes ou sistemas legados, um servidor SFTP pode complementar Restic e Borg sem expor shell completo.

Como pensar a arquitetura de uma VPS de backup

Um servidor de backup remoto não deve ser apenas uma pasta grande em outra máquina. Ele precisa ter papel bem definido, poucas portas abertas, usuários separados por origem e uma política clara de retenção. A ideia básica é simples: seus servidores de produção enviam arquivos, dumps de banco e metadados para a VPS de backup, usando Restic, Borg ou SFTP. A parte difícil está nos detalhes. Quem pode apagar repositórios? Onde ficam as senhas? Quanto tempo os dados permanecem? Como você recupera um banco de 40 GB às 3 da manhã?

Servidor de backup não é servidor de produção

A primeira decisão é separar funções. Não rode site, banco, painel administrativo e backup no mesmo servidor. Se um atacante comprometer a VPS de produção e encontrar as mesmas chaves com permissão de escrita e exclusão no destino, ele pode apagar tudo. Um desenho mais seguro usa uma VPS dedicada ao backup, sem serviços públicos além do SSH, com firewall liberado apenas para IPs conhecidos. Em ambientes pequenos, isso já reduz bastante o risco.

Um exemplo prático: uma loja WooCommerce em uma VPS principal pode gerar, toda madrugada, um dump comprimido do MariaDB, copiar uploads recentes e enviar tudo para um repositório Restic em uma VPS remota. O servidor de backup não precisa conhecer a senha do WordPress nem aceitar tráfego HTTP. Ele só recebe dados via SSH. Se você já usa mecanismos locais, o artigo sobre VPS com backup automático ajuda a separar o que é rotina do provedor e o que deve ser sua estratégia de cópia independente.

Restic, Borg e SFTP no desenho da solução

Restic e Borg ocupam uma camada acima do transporte. Eles dividem dados em blocos, deduplicam conteúdo repetido, criptografam o repositório e criam snapshots lógicos. O SFTP, por sua vez, é mais simples: transfere arquivos para uma área remota. Ele é útil quando você precisa integrar sistemas antigos, clientes sem agente de backup ou rotinas que só sabem enviar arquivos. Para esse cenário, vale cruzar este artigo com o guia de VPS para servidor SFTP no Brasil, principalmente se a latência para usuários brasileiros e o controle de acesso por diretório forem relevantes.

Uma arquitetura comum combina os dois mundos. O servidor de produção usa Restic ou Borg para dados críticos, como banco, configurações, diretórios de aplicação e arquivos de usuário. Já integrações simples enviam relatórios, exports ou arquivos de clientes por SFTP para uma pasta separada. O ponto central é não misturar permissões. Um usuário chamado backup-app1 não deve enxergar repositórios de backup-app2. Parece burocracia, mas esse isolamento evita que um erro de script apague dados de todos os projetos ao mesmo tempo.

Restic ou Borg: diferenças práticas antes de instalar

Restic e Borg resolvem o mesmo problema, mas não são ferramentas idênticas. As duas oferecem backups incrementais, criptografia, deduplicação e verificação de integridade. A escolha costuma depender do ambiente, do backend desejado e do perfil de operação. Se você quer enviar backup para S3, Backblaze B2, MinIO ou outro armazenamento compatível, Restic geralmente é mais direto. Se você quer usar SSH para uma VPS própria e extrair o máximo de eficiência com compressão e deduplicação, Borg costuma ser muito forte.

Quando Restic costuma encaixar melhor

Restic tem uma vantagem clara em portabilidade. Ele trabalha com vários backends, incluindo local, SFTP, REST server e serviços compatíveis com objeto. Em uma VPS de backup, você pode criar um repositório via SFTP e, no futuro, migrar ou replicar para outro destino. O fluxo básico é fácil de entender: definir RESTIC_REPOSITORY, definir RESTIC_PASSWORD_FILE, inicializar o repositório e executar restic backup /caminho. Um exemplo simples seria proteger /var/www, /etc/nginx e um dump diário em /var/backups/mysql.

Na prática, Restic é bastante confortável para equipes que trabalham com automação. Um script pode exportar variáveis de ambiente, executar o backup, aplicar retenção com restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune e depois rodar restic check. Isso cria uma rotina legível para revisar em Git. O cuidado é não colocar a senha do repositório dentro do script versionado. Use arquivo com permissão 600, secret manager, variável protegida no CI ou cofre externo.

Quando Borg faz mais sentido

Borg brilha quando o destino é uma máquina acessível por SSH e você quer backup eficiente de muitos arquivos pequenos. Ele usa repositórios próprios, tem compressão configurável e permite padrões de retenção bem maduros com borg prune. Em servidores Linux tradicionais, é comum ver Borg protegendo /home, /etc, dumps de PostgreSQL e diretórios de aplicações. Um comando como borg create --stats backup@servidor:/repo::app-{now} /etc /var/www /var/backups/postgres já cria um snapshot deduplicado e criptografado.

Borg também tem um recurso operacional interessante: o modo append-only no lado do servidor. Ele não é uma blindagem perfeita contra todos os ataques, mas reduz a chance de um cliente comprometido apagar backups antigos imediatamente. Mesmo assim, não confunda append-only com imutabilidade absoluta. Um administrador com acesso root na VPS de backup ainda pode remover dados. Para proteção mais forte, você precisa combinar permissões restritas, cópias secundárias, snapshots do volume e, em alguns casos, armazenamento com retenção bloqueada.

Dimensionamento da VPS: CPU, RAM, disco e rede

O erro mais comum ao montar uma VPS para backups com Restic e Borg é comprar pelo tamanho atual dos dados e esquecer retenção, crescimento e margem de restauração. Se o servidor de produção tem 80 GB úteis, isso não significa que 100 GB no destino resolvem. Backups incrementais deduplicados economizam bastante espaço, mas arquivos que mudam muito, como dumps de banco, logs comprimidos, imagens geradas e exports diários, consomem disco rapidamente. Uma regra inicial prudente é provisionar de 3 a 5 vezes o volume útil protegido para retenção de 30 a 90 dias.

Estimando espaço com retenção

Imagine uma API com 25 GB de arquivos estáveis, 10 GB de banco e 5 GB de uploads novos por semana. Se o dump do banco muda todos os dias e você guarda 30 diários, o consumo pode passar de 300 GB só em dumps, mesmo com compressão. Uma abordagem melhor é gerar dump com compressão, separar tabelas grandes quando fizer sentido e usar retenção ajustada: 7 diários, 4 semanais e 6 mensais. Para Restic, o comando forget aplica essa política. Para Borg, borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 faz papel parecido.

CPU e RAM pesam menos que disco, mas não podem ser ignoradas. Para uma VPS de backup pequena, 1 vCPU e 1 GB de RAM podem funcionar, especialmente se ela apenas recebe dados. Para repositórios maiores, verificações frequentes e compressão mais pesada no Borg, 2 vCPUs e 2 a 4 GB de RAM deixam a operação mais previsível. Se a VPS também roda monitoramento, relatórios e sincronização para outro destino, suba para 4 GB ou 8 GB de RAM.

Rede, latência e janela de backup

Rede define a janela de backup. Um primeiro envio de 200 GB por uma conexão real de 100 Mbps pode levar mais de 4 horas e meia em condições ideais, sem contar criptografia, latência e limitação de I/O. Depois, os incrementais serão menores, mas uploads de mídia, vídeos e dumps grandes ainda podem estourar a madrugada. Para público e servidores no Brasil, uma VPS com datacenter nacional tende a reduzir latência e tornar restaurações emergenciais mais rápidas, mas confirme localidade e condições de banda no site oficial do provedor antes de decidir.

Também pense no caminho inverso. Backup bom precisa voltar. Restaurar 150 GB durante um incidente exige rede estável, disco rápido e procedimento ensaiado. Se a sua estratégia depende de reconstruir uma VPS do zero, instale dependências por automação e restaure dados depois. Se depende de rollback imediato, combine backup remoto com snapshots locais. O conteúdo sobre VPS com snapshots para recuperação rápida explica bem essa diferença entre voltar o estado de uma máquina e recuperar dados históricos.

Configuração segura do servidor remoto

A segurança da VPS de backup começa antes da instalação do Restic ou Borg. O servidor deve nascer com acesso mínimo: login root por SSH desativado, autenticação por senha bloqueada, chaves SSH individuais, firewall liberando apenas a porta necessária e atualizações automáticas de segurança quando forem compatíveis com sua operação. Em Ubuntu ou Debian, uma base comum inclui ufw, fail2ban, usuários sem shell interativo quando possível e diretórios com permissões restritas.

Usuário restrito, SSH e firewall

Um exemplo de organização: crie um usuário por origem, como backup-web1, backup-db1 e backup-agencia. Cada usuário recebe seu diretório em /srv/backups/nome, com dono e permissões isoladas. No SSH, use chaves específicas por servidor de produção. No arquivo authorized_keys, é possível aplicar restrições, como comando forçado, bloqueio de encaminhamento de porta e origem por IP. Para Borg, ferramentas como borg serve permitem restringir o acesso ao repositório. Para SFTP, internal-sftp e ChrootDirectory ajudam a prender o usuário em uma árvore específica.

No firewall, a regra deve ser conservadora. Se apenas duas VPS de produção enviam backup, libere SSH somente para os IPs delas. Exemplo com UFW: ufw default deny incoming, ufw allow from 203.0.113.10 to any port 22 proto tcp e ufw enable. Em provedores cloud, replique a regra também no firewall de rede quando existir. Não dependa de uma única camada. Se um painel permitir regras por security group, use-o para bloquear tráfego antes mesmo de chegar ao sistema operacional.

Criptografia e chaves fora do servidor

Restic e Borg criptografam os dados no repositório, mas isso não resolve tudo se a senha estiver exposta no mesmo lugar que o script. O ideal é manter a chave de criptografia fora da VPS de backup e fora do repositório Git. No servidor de produção, salve a senha em /root/.config/restic/password com permissão 600, injete via secret de CI ou use um cofre. Para Borg, proteja a passphrase com o mesmo cuidado. Se alguém obtiver a senha e acesso ao destino, poderá ler ou manipular backups.

Também documente o processo de recuperação da chave. Parece simples, até o único administrador sair da empresa ou perder o notebook. Guarde instruções em um cofre de senhas corporativo, com acesso de emergência para pelo menos duas pessoas autorizadas. Em times pequenos, isso evita um desastre silencioso: backup íntegro, repositório presente, mas impossível de descriptografar. Segurança boa não é só impedir acesso indevido, é garantir acesso legítimo quando tudo está fora do ar.

Retenção, automação e verificação dos backups

A política de retenção define quanto tempo você consegue voltar no passado. Sem retenção, o backup vira um acúmulo caro e difícil de auditar. Com retenção agressiva demais, você descobre tarde que apagou justamente o ponto anterior a uma corrupção de banco. Para muitos projetos web, uma base equilibrada é manter 7 backups diários, 4 semanais e 6 mensais. Sistemas financeiros, ERPs e SaaS com obrigações contratuais podem precisar de janelas maiores, cópias offline e retenção legal específica.

Política de retenção por perfil

Para um blog WordPress pequeno, uma rotina diária de arquivos e banco pode ser suficiente, com retenção de 14 dias e 3 meses mensais. Para uma loja online, eu separaria banco, uploads e configurações, mantendo pelo menos 30 dias de pontos diários ou quase diários, porque erros de catálogo, pedidos e plugins podem demorar a aparecer. Para um SaaS B2B, a retenção deve considerar RPO e RTO. RPO de 24 horas significa aceitar perder até um dia de dados. Em muitos SaaS, isso é alto demais. Pode ser necessário backup a cada 6 horas ou replicação adicional.

Com Restic, uma rotina simples poderia rodar às 02:10: gerar dump do banco, executar restic backup, aplicar restic forget --prune e enviar log para e-mail ou webhook. Com Borg, o ciclo equivalente é borg create, borg prune e borg compact quando aplicável. Use systemd timer se quiser logs integrados ao journal e controle mais robusto que cron. Cron ainda funciona bem, mas falhas podem passar despercebidas se você não capturar saída e código de retorno.

Testes de integridade e restauração

Verificação não é enfeite. Restic tem restic check, além de opções para ler subconjuntos de dados. Borg tem borg check, que pode validar repositório e arquivos. Rodar verificação completa todos os dias em repositórios grandes pode ser caro. Uma estratégia prática é checagem leve diária, checagem mais profunda semanal e restore mensal em ambiente temporário. O teste precisa restaurar arquivos reais, validar permissões e, quando houver banco, subir a aplicação contra uma cópia.

Um exemplo de restore testado: toda primeira segunda-feira do mês, criar uma VPS temporária, instalar stack via Ansible, restaurar /etc/nginx, /var/www e o dump mais recente do PostgreSQL, depois rodar uma checagem HTTP interna. Se isso parece exagero, pense no custo de descobrir durante um incidente que o dump estava truncado há 45 dias. Backup silencioso é perigoso. Log verde sem restauração testada não prova recuperação.

Tabela comparativa: perfis de VPS para backup

A tabela abaixo não é uma comparação de preços, porque valores, promoções, banda e localidades mudam com frequência e precisam de revisão humana antes da publicação. Ela serve como referência técnica para dimensionar uma VPS de backup por perfil de uso. Ajuste sempre pelo volume real de dados, taxa diária de mudança, compressibilidade e janela de restauração. Arquivos de texto, configurações e código deduplicam muito bem. Imagens, vídeos, dumps comprimidos e arquivos já criptografados deduplicam menos.

Perfil de uso	Configuração inicial sugerida	Volume protegido típico	Retenção prática	Ferramenta mais comum	Observações operacionais
Projeto pessoal ou dev solo	1 vCPU, 1 GB RAM, 80 a 160 GB SSD	10 a 40 GB	7 diários, 4 semanais, 3 mensais	Restic via SFTP	Bom para sites pequenos, repositórios Git privados, configs e dumps leves
Agência ou pequena equipe	2 vCPUs, 2 a 4 GB RAM, 300 a 800 GB SSD	80 a 250 GB	14 a 30 diários, 8 semanais, 6 mensais	Borg via SSH ou Restic	Separe usuários por cliente e monitore crescimento semanal do disco
Produção crítica	4 vCPUs, 8 GB RAM, 1 TB ou mais	300 GB a múltiplos TB	Política por RPO, RTO e contrato	Borg, Restic e cópia secundária	Combine backup remoto, snapshots, teste de restauração e alertas fora do servidor
Dados com muitos arquivos pequenos	2 vCPUs, 4 GB RAM, SSD com bom IOPS	100 a 500 GB	30 diários e mensais seletivos	Borg	Deduplicação e compressão ajudam, mas checks podem exigir mais CPU e tempo
Arquivos grandes de mídia	2 a 4 vCPUs, 4 GB RAM, 1 TB ou mais	500 GB a vários TB	Menos pontos, retenção por versão	Restic ou SFTP organizado	Planeje banda, janela de envio e restauração parcial por diretório

Além da configuração, escolha um provedor que permita expansão de disco sem migração traumática, tenha datacenter adequado ao seu cenário e ofereça console de emergência. DigitalOcean, Vultr, Linode Akamai, AWS Lightsail, Hetzner, Contabo e provedores brasileiros podem atender perfis diferentes, mas localidade, armazenamento, tráfego incluso e política de snapshots precisam ser conferidos nas páginas oficiais. LetsCloud pode entrar no radar quando fizer sentido usar infraestrutura com presença voltada ao mercado brasileiro, mas disponibilidade de NVMe, regiões, backups, snapshots e condições comerciais devem ser validadas por plano e localidade antes de qualquer recomendação fechada.

Na prática, o melhor perfil é aquele que você consegue operar. Uma VPS enorme sem alerta de disco pode falhar do mesmo jeito que uma pequena. Configure monitoramento de uso, inode, falhas de job e idade do último backup. Se o último snapshot válido tem mais de 24 horas e seu RPO é diário, acenda alerta. Se o disco passou de 80 por cento, aja antes do prune falhar. Backup não gosta de improviso.

Recuperação: o backup só vale quando volta

Toda estratégia de backup precisa responder a duas perguntas simples: quanto dado posso perder e quanto tempo posso ficar fora do ar? A primeira é RPO. A segunda é RTO. Restic e Borg ajudam muito, mas não fazem milagre se a recuperação não foi planejada. Restaurar um arquivo de configuração é uma coisa. Restaurar um banco de 200 GB, reconfigurar permissões, trocar DNS e validar aplicação é outra. Por isso, o procedimento de restore deve existir antes do incidente.

Restauração parcial

A restauração parcial é o caso mais comum no dia a dia. Alguém apagou uma pasta de uploads, um deploy removeu um arquivo de configuração, uma tabela foi exportada incorretamente. Com Restic, você pode listar snapshots com restic snapshots, montar o repositório com restic mount /mnt/restic ou restaurar um caminho específico com restic restore latest --target /tmp/restore --include /var/www/site/uploads. Com Borg, use borg list, borg mount ou borg extract para recuperar arquivos pontuais.

Esse tipo de restore deve ser treinado com calma. Defina onde os arquivos serão restaurados, quem valida o conteúdo e como evitar sobrescrever dados atuais. Uma boa prática é restaurar em /tmp/restore-data ou em uma VPS temporária, comparar conteúdo e só depois copiar para produção. Para banco de dados, nunca importe diretamente sobre produção sem snapshot ou dump atual. Gere um backup do estado presente antes de tentar corrigir o passado.

Restauração completa em incidente

Em falha séria, como perda total da VPS principal, o caminho precisa ser quase um roteiro. Criar nova instância, aplicar hardening, instalar pacotes, restaurar configurações, restaurar dados, subir serviços, validar logs, trocar DNS e monitorar. Se isso depende de memória humana, vai dar errado sob pressão. Use Ansible, scripts de bootstrap ou documentação passo a passo. Mesmo uma planilha operacional já é melhor que depender do histórico do terminal de alguém.

Snapshots do provedor entram como acelerador, não como substituto. Eles são ótimos para voltar rapidamente após atualização ruim ou erro de configuração. Porém, se a conta do provedor for comprometida, se o volume for apagado ou se a corrupção lógica já estiver no snapshot, você precisa de backup independente. A combinação saudável é ter snapshot para recuperação rápida e Restic ou Borg para histórico criptografado fora do ambiente principal. Em incidentes reais, camadas diferentes salvam por motivos diferentes.

Recomendações por perfil

Dev solo e freelancer

Para um dev solo, a prioridade é simplicidade sem abrir mão de criptografia. Uma VPS de 1 vCPU, 1 GB de RAM e 80 a 160 GB de SSD costuma atender sites pequenos, APIs pessoais, repositórios privados e dumps leves. Restic via SFTP é uma boa primeira escolha porque o fluxo é direto, os comandos são legíveis e a migração para backend compatível com objeto fica mais fácil no futuro. Use uma senha longa em arquivo protegido, backup diário, retenção de 7 diários, 4 semanais e 3 mensais. Faça restore mensal de pelo menos um projeto real.

Pequena equipe ou agência

Agências e pequenas equipes precisam isolar clientes. Não use um único usuário SSH para todos os projetos. Crie repositórios separados, defina cotas quando possível e monitore crescimento por cliente. Uma VPS com 2 vCPUs, 2 a 4 GB de RAM e 300 a 800 GB de SSD é um ponto de partida razoável para dezenas de sites pequenos ou alguns projetos médios. Borg pode ser interessante quando há muitos arquivos repetidos e servidores Linux padronizados. Restic encaixa melhor quando a equipe quer flexibilidade de backend. Em ambos os casos, envie alertas para um canal compartilhado, não para o e-mail de uma única pessoa.

Produção crítica e operação recorrente

Para produção crítica, não compre VPS de backup pensando só em menor custo mensal. Pense em RPO, RTO, auditoria, acesso emergencial, criptografia, retenção e cópia secundária. Use pelo menos 4 vCPUs, 8 GB de RAM e armazenamento dimensionado com margem, especialmente se houver bancos grandes ou múltiplos servidores. Combine Restic ou Borg com snapshots, monitoramento externo e restore testado em ambiente temporário. Guarde chaves em cofre corporativo, mantenha procedimento documentado e revise permissões a cada mudança de equipe. Se houver exigência regulatória, valide retenção, localização dos dados e exclusão segura com apoio jurídico e técnico.