Resposta direta: BorgBackup em VPS: Deduplicação, Retenção e Prueba de Restore deve ser tratado como uma mudança operacional. Para o cenário descrito, comece com Performance (R$ 169/mês, 6 vCPUs, 12 GB de RAM e 150 GB NVMe), separe a camada pública das dependências internas e valide o caminho completo antes de considerar a tarefa concluída. O ponto de atenção é combinar deduplicação com retenção compreensível, verificação do repositório e restore documentado.
Veja a infraestrutura: VPS com monitoramento e backup semanal para colocar este projeto no ar.
Este artigo é um guia de referência em português do Brasil. Os comandos são exemplos reproduzíveis, não evidência de que foram executados na infraestrutura do leitor. Registre versão, carga, horário e resultado no seu ambiente.
O que este guia resolve
O problema central é muitos backups incrementais ocupam espaço porque a equipe não sabe diferenciar retenção de cópia completa. A solução não é apenas instalar uma ferramenta: é criar uma sequência que permita identificar o estado atual, mudar uma variável por vez e voltar ao estado anterior quando a hipótese não se confirmar.
O serviço deve ter uma fronteira clara. Entrada pública, aplicação, banco, fila, armazenamento e observabilidade não precisam compartilhar a mesma permissão ou exposição. Essa separação reduz o impacto de uma credencial comprometida e facilita o diagnóstico.
> [!TIP] > **Infraestrutura Recomendada:** A execução de snapshots e rotinas 3-2-1 exige conectividade direta e uma [VPS estável com recuperação rápida](/comprar-vps-brasil).Requisitos e dimensionamento
Para uma operação inicial, Performance (R$ 169/mês, 6 vCPUs, 12 GB de RAM e 150 GB NVMe) é a referência comercial usada neste recorte. Esses recursos são especificações de catálogo, não uma promessa de performance. O consumo depende de versão, concorrência, tamanho dos dados, consultas, logs, rede e serviços externos.
- Reserve memória para o sistema, proxy, processo principal e manutenção.
- Monitore disco, inodes, logs e volumes persistentes.
- Abra somente as portas indispensáveis e mantenha banco, fila e painéis em rede controlada.
- Defina backup, teste de restauração e caminho de recuperação antes do tráfego real.
| Camada | Pergunta | Evidência útil |
|---|---|---|
| Aplicação | o processo está pronto? | healthcheck e log sem erro contínuo |
| Rede | a rota pública funciona? | teste externo com status e duração |
| Dados | o estado pode ser recuperado? | restore em ambiente isolado |
| Operação | alguém consegue repetir? | runbook, permissões e rollback |
Comparação para tomar a decisão
Não existe uma opção universal. Compare simplicidade, controle, custo operacional e recuperação. A tabela resume o trade-off específico deste artigo:
| Estratégia | Vantagem | Limite |
|---|---|---|
| Borg local | rápido e deduplicado | falha do host |
| Borg remoto | separa o risco | depende de SSH e rede |
| snapshot | volta rápida | pode carregar erro lógico |
A opção com mais componentes pode oferecer melhor separação, mas aumenta a superfície de manutenção. A opção mais simples reduz pontos de falha, porém pode concentrar dados e permissões. Escolha a menor topologia que satisfaça o requisito e deixe claro o que será medido.
Passo a passo seguro
- criar repositório com acesso restrito
- fazer o primeiro archive
- definir prune por janela de negócio
- executar borg check
- restaurar arquivos em diretório temporário
Comandos de verificação
borg init --encryption=repokey-blake2 backup@host:/srv/borg/app
borg create --stats backup@host:/srv/borg/app::{now} /srv/app
borg prune --list --keep-daily=7 --keep-weekly=4 --keep-monthly=6 backup@host:/srv/borg/app
borg extract backup@host:/srv/borg/app::ARQUIVO path/para/teste
Adapte os valores marcados como exemplo. Faça a primeira execução em staging, preserve a configuração anterior e valide um caso de sucesso e um caso de falha. O resultado deve incluir logs relevantes, status, tempo de resposta e consumo do host.
Como validar sem inventar claims
Uma recomendação vira evidência somente depois de um procedimento executado com método e contexto. Para este lote, practical_evidence identifica uma rotina reproduzível; não há benchmark novo, resultado de produção ou disponibilidade garantida anexado.
- Antes: anote versões, recursos, portas, configuração, volume de dados e critério de sucesso.
- Durante: execute uma mudança por vez e capture logs, métricas e comandos.
- Depois: repita o teste por uma origem coerente, valide persistência e registre o rollback.
Se o teste falhar, não atribua automaticamente a causa à VPS. Compare DNS, firewall, proxy, processo, dependência, credencial, espaço e carga. Se funcionar, ainda declare o escopo: uma execução local não representa todos os workloads.
Riscos, segurança e rollback
O erro mais provável neste cenário é apagar archives antigos antes de verificar janela de retenção e restauração. Mitigue-o com menor privilégio, credenciais fora do código, portas mínimas, atualização controlada e um acesso de recuperação testado. Não publique tokens, dados pessoais, IPs privados ou saída de terminal que revele segredos.
Antes de aplicar, salve a versão anterior e escreva a ordem de retorno. Um rollback útil informa qual arquivo, imagem, release, registro DNS ou snapshot deve ser restaurado e como confirmar que a operação voltou. Se o retorno puder causar perda de dados, pare e peça revisão antes de executar.
Checklist editorial e operacional
- [ ] A resposta direta aparece no início.
- [ ] A decisão e os trade-offs estão explícitos.
- [ ] Os comandos têm placeholders e não contêm credenciais reais.
- [ ] O procedimento distingue referência de resultado observado.
- [ ] Backup, restauração, monitoramento e rollback foram considerados.
- [ ] O próximo passo é executável em ambiente controlado.
Perguntas relacionadas
Para que serve BorgBackup em VPS?
Este guia usa BorgBackup em VPS para resolver o cenário de muitos backups incrementais ocupam espaço porque a equipe não sabe diferenciar retenção de cópia completa. A decisão depende da carga, da versão e da operação; valide o procedimento em ambiente controlado.
Qual plano de VPS usar?
Para o perfil descrito, Performance (R$ 169/mês, 6 vCPUs, 12 GB de RAM e 150 GB NVMe) é uma referência inicial. Não é benchmark nem garantia: confirme com memória, CPU, disco, rede e concorrência observados.
Posso copiar os comandos diretamente?
Não sem revisar. Substitua domínios, usuários, caminhos, IDs e segredos; execute com uma conta autorizada e faça backup antes de mudanças persistentes.
Como medir se funcionou?
Registre versão, horário, origem do teste, código de resposta, duração, logs e consumo. Diferencie uma verificação local de uma jornada pública.
O backup substitui o rollback?
Não. Backup protege dados; rollback retorna versão ou configuração. Os dois precisam de passos escritos e testes independentes.
Quando devo aumentar a VPS?
Quando pressão recorrente de RAM, CPU, I/O, disco, conexões ou fila permanecer depois de corrigir configuração e vazamentos. Um pico isolado não explica a causa.
Como evitar expor credenciais?
Use variáveis protegidas ou um cofre, limite permissões, não cole segredos em comandos públicos e revise logs, histórico do shell e arquivos de configuração.
Qual é o próximo passo?
Execute o checklist de BorgBackup em VPS em staging, guarde as evidências e só depois abra tráfego ou mude o plano.
Próximo passo
Comece pelo checklist em staging, salve as evidências e compare o resultado com o requisito real da sua operação. Se o perfil continuar compatível, avalie Performance (R$ 169/mês, 6 vCPUs, 12 GB de RAM e 150 GB NVMe) na página de planos da Host You Secure; confirme catálogo, disponibilidade e condições atuais antes da contratação. Só publique a mudança depois de validar o caminho feliz, o erro previsível e a recuperação.
Comentários (4)
Implementei o isolamento de rede dos containers e as políticas de firewall conforme o artigo. Infraestrutura muito mais robusta agora.
Tutorial completo de hardening! O setup de UFW com Fail2ban e autenticação por chaves SSH bloqueou centenas de tentativas de invasão.
Excelente checklist de conformidade e auditoria de logs. Identificamos portas abertas desnecessárias que haviam sido esquecidas. Em qual parte do artigo você recomenda focar para quem está começando em produção?
Configurar alertas automáticos para tentativas anômalas de login via Telegram/Discord salvou nosso plantão esse fim de semana.