A regra 3-2-1 é o consenso mais sólido em proteção de dados: 3 cópias, em 2 mídias diferentes, sendo 1 fora do local. Simples de enunciar, e é justamente por parecer simples que tanta gente a implementa pela metade. Veja como aplicá-la de verdade com o Proxmox Backup Server (PBS).

Por que 3-2-1 ainda é o padrão

Cada número resolve um tipo de desastre:

• 3 cópias protegem contra falha de mídia — um disco morre, você tem outras duas.
• 2 mídias diferentes protegem contra um problema sistêmico de um tipo de armazenamento.
• 1 fora do local protege contra o desastre físico: incêndio, roubo, enchente, ou um ataque de ransomware que criptografa tudo que está online.

Ignorar o "1 off-site" é o erro mais perigoso. Backup que mora ao lado do servidor de produção morre junto com ele.

Antes das cópias: defina RPO e RTO

Toda decisão de backup deriva de duas perguntas que só o negócio responde:

• RPO (quanto dado você aceita perder): se o backup roda uma vez por dia, você aceita perder até um dia de trabalho. Sistemas transacionais costumam exigir muito menos que isso, o que empurra para backups mais frequentes ou para replicação na camada da aplicação.
• RTO (em quanto tempo precisa voltar): define arquitetura, não só ferramenta. Voltar em quinze minutos exige repositório rápido e próximo; voltar em um dia permite depender só do site remoto.

Escrever esses dois números por sistema — não um número único para tudo — é o que transforma backup de rotina técnica em política de continuidade. Sem eles, qualquer desenho é chute, e a discussão sobre custo não tem âncora.

Aplicando com o PBS

A cópia 1 e 2: primário e secundário

O primeiro repositório PBS fica próximo da produção, para backups rápidos e restaurações imediatas. Com deduplicação e compressão Zstandard, ele ocupa pouco e roda incrementais ágeis.

Para a segunda cópia, o PBS oferece sync jobs: você replica o repositório para um segundo servidor PBS, em outra máquina ou local. Isso cria a segunda mídia/instância sem refazer backup da produção — o sync copia só o que mudou.

A cópia off-site

O segundo PBS pode (e deve, na maioria dos casos) ficar em outro site. Se você opera em dois locais — como São Paulo e Chapecó —, replicar o backup entre eles cobre o requisito off-site com infraestrutura própria. Alternativas incluem um repositório em nuvem ou storage remoto dedicado.

Um detalhe de arquitetura que vale ouro: configure o sync no modo em que o servidor remoto puxa os dados do primário, em vez de o primário empurrar. Assim, as credenciais de escrita no repositório externo não ficam guardadas no ambiente de produção. Se a produção for comprometida, o invasor não encontra ali a chave para apagar a cópia externa.

A camada extra: mídia offline

Para dados críticos, vale uma cópia que fique desconectada — fita ou disco removível guardado fora de linha. É a defesa final contra ransomware: o que não está acessível pela rede não pode ser criptografado por um invasor. O PBS suporta backup em fita nativamente, o que mantém esse fluxo dentro da mesma ferramenta.

O mapa completo: cada número e sua peça

Da regra 3-2-1 para 3-2-1-1-0

A prática moderna estendeu a regra em resposta ao ransomware, e a versão ampliada vale ser conhecida: além das três cópias, duas mídias e uma externa, acrescenta-se uma cópia imutável ou offline e zero erros de verificação. O segundo item é o mais barato de implementar e o mais esquecido: não basta ter as cópias, é preciso que a verificação de integridade rode e passe.

Retenção: quanto tempo guardar

Backup sem política de retenção vira ou um repositório infinito (caro) ou um monte de cópias inúteis. O PBS deixa você definir quantos backups diários, semanais, mensais e anuais manter — o esquema de prune. Ajuste conforme o valor do dado e as exigências de conformidade do seu negócio.

Um ponto de operação que gera muito chamado desnecessário: o prune apenas marca os snapshots que saíram da política. Quem libera espaço em disco de fato é o garbage collection, removendo os blocos que nenhum backup referencia mais. Sem GC agendado, o datastore enche mesmo com a retenção configurada corretamente.

Uma política inicial que serve à maioria dos ambientes e depois se ajusta:

Ambientes com obrigação regulatória precisam checar o prazo mínimo exigido pelo setor antes de definir esses números — e considerar que retenção longa é decisão de custo, não só de segurança.

Janela de backup: cabe no seu dia?

Retenção resolve o passado; a janela resolve o presente. Vale confirmar três coisas: se todos os jobs terminam antes do início do expediente, se o tráfego de backup não compete com produção na mesma interface de rede, e se as tarefas de verificação e GC têm horário próprio, fora do pico. Backup que atropela a produção acaba desligado por alguém — e aí a estratégia inteira cai.

O passo que quase todo mundo pula: verificar

Backup que nunca foi testado é esperança, não estratégia. Duas práticas obrigatórias:

1. Verificação de integridade do PBS: ele confere periodicamente os checksums e aponta corrupção antes de você precisar restaurar.
2. Teste de restauração real: de tempos em tempos, restaure uma VM em ambiente isolado e confirme que ela sobe e funciona. É a única prova de que o plano funciona.

Um roteiro de teste que caberia em uma manhã por trimestre:

• Escolher um sistema crítico, sem avisar o time com muita antecedência.
• Restaurar em rede isolada, cronometrando cada etapa.
• Validar não só o boot, mas a aplicação, com quem a usa de fato.
• Testar também a restauração de arquivo único, que é o caso mais frequente do dia a dia.
• Registrar o tempo total e comparar com o RTO prometido.
• Corrigir o que apareceu — e é normal aparecer algo.

Esse número cronometrado é o que permite prometer prazo de recuperação com honestidade, em vez de esperança.

Automatize e monitore

3-2-1 só é confiável se roda sozinho e avisa quando falha. Agende os jobs de backup e sync, configure alertas de falha e acompanhe se as janelas estão sendo cumpridas. Backup silencioso que parou há três semanas é o pesadelo clássico.

Monitore, no mínimo: sucesso e duração dos jobs de backup, sucesso dos syncs para o site remoto, resultado das verificações, espaço livre no datastore e data do último teste de restauração. E garanta que o alerta chegue a uma pessoa de plantão, não a uma caixa compartilhada que ninguém lê.

Um plano de 30 dias para sair do zero

1. Semana 1: levantar sistemas, definir RPO e RTO por sistema, subir o PBS primário e colocar todas as VMs em backup diário.
2. Semana 2: configurar criptografia, guardar a chave fora do ambiente, definir a política de retenção e agendar prune e garbage collection.
3. Semana 3: subir o PBS secundário em outro site, configurar o sync no modo pull e habilitar as verificações periódicas.
4. Semana 4: executar o primeiro teste de restauração cronometrado, ligar os alertas e documentar o procedimento de recuperação para quem estiver de plantão.

Em um mês você sai de "temos backup" para "sabemos exatamente o que acontece quando precisar".

Erros comuns

• Backup no mesmo storage ou no mesmo servidor da produção.
• Cópia externa que nunca foi confirmada — o sync falha em silêncio há semanas.
• Chave de criptografia guardada apenas dentro do ambiente que ela protege.
• Prune configurado, GC esquecido, datastore lotando.
• Credencial de escrita no repositório externo salva na produção.
• Nenhuma restauração de teste nos últimos doze meses.

Onde a Solvefy/Cloud entra

Desenhamos e sustentamos estratégias 3-2-1 completas com PBS: repositório primário, sync para site secundário, retenção alinhada ao seu risco, verificação e testes de restauração. Como parceiros oficiais Proxmox, cuidamos para que o backup exista, restaure e restaure rápido.

Quer auditar sua estratégia de backup atual? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.