A regra 3-2-1 nasceu num mundo de disco local e fita: três cópias dos dados, em dois tipos de mídia, com uma fora do local. Ela sobreviveu porque é fácil de lembrar e porque resume uma ideia correta — redundância só serve quando as cópias falham por motivos diferentes.

O problema é que, na nuvem, é trivial satisfazer os três números no papel e continuar com uma cópia só na prática. Bucket de origem, bucket de réplica em outra região e versionamento habilitado dão três artefatos distintos. Se os três vivem na mesma conta, respondem à mesma credencial administrativa e são regidos pelas mesmas políticas, eles compartilham o modo de falha mais provável. A contagem diz três. O domínio de falha diz um.

O que cada número protege

Vale desmontar a regra antes de aplicá-la.

Os 3 (três cópias) protegem contra falha independente de mídia. A premissa é probabilística: se cada cópia falha por conta própria, a chance de todas falharem ao mesmo tempo é o produto das chances individuais. A premissa cai inteira quando as falhas são correlacionadas.

Os 2 (duas mídias) existem para quebrar essa correlação. Dois discos do mesmo lote, no mesmo controlador, com o mesmo firmware, não são duas mídias para efeito prático — são duas instâncias do mesmo risco. A regra pede tecnologias que não falhem pelo mesmo defeito.

O 1 (uma fora do local) protege contra o evento que atinge o local inteiro: incêndio, alagamento, roubo, queda de energia prolongada. É a única parte da regra que trata de um desastre com raio de alcance, e não de um componente.

Note que nenhum dos três números fala de permissão, de identidade ou de API. Quando a regra surgiu, isso não era omissão: para apagar a fita era preciso tocar na fita.

A fronteira que importa na nuvem é a conta

A pergunta útil não é "quantas cópias eu tenho?". É "o que precisa dar errado para eu perder todas?". Na nuvem, a resposta quase sempre aponta para a conta — ou tenancy, ou subscription, conforme o provedor.

Dentro de uma mesma conta, estes eventos alcançam todas as cópias de uma vez:

Credencial administrativa comprometida. Quem tem o poder de criar política tem o poder de remover proteção e apagar. Réplica em outra região obedece à mesma raiz de confiança.
Automação própria defeituosa. Um script de limpeza com prefixo errado, uma política de ciclo de vida aplicada ao bucket errado, um terraform destroy em workspace trocado.
Política de ciclo de vida. Regra de expiração criada por uma equipe convive mal com retenção criada por outra. O dado some sem que ninguém tenha apagado nada de propósito.
Suspensão ou encerramento de conta. Inadimplência, fraude suspeita, disputa contratual. O acesso cai para tudo que está sob aquele identificador de cobrança.
Exclusão do próprio projeto ou compartimento. O contêiner some com o conteúdo.

Qualquer um desses eventos transforma três cópias em zero. É por isso que, para fins de 3-2-1, cópias que dependem da mesma credencial e da mesma política contam como uma.

Versionamento e réplica não são a segunda cópia

Dois casos merecem nome, porque aparecem com frequência em desenho de arquitetura.

Versionamento mantém versões anteriores de um objeto no mesmo bucket. Protege contra sobrescrita e contra exclusão acidental simples — a exclusão cria um marcador, e a versão antiga continua lá. Não protege contra exclusão de versão por quem tem permissão para isso, nem contra remoção do bucket, nem contra regra de ciclo de vida que expira versões não correntes. É um recurso dentro do mesmo objeto de infraestrutura, descrito na documentação de versionamento do S3. Conte como resiliência local, não como cópia.

Replicação entre regiões cobre indisponibilidade regional e perda de mídia em escala geográfica. Não cobre comando autenticado: a replicação é unidirecional para o dado, mas o plano de controle é compartilhado. Um atacante com permissão na conta edita a configuração de replicação ou apaga o bucket de destino. Pior: se a replicação propaga exclusões, ela é um canal de dano, não uma barreira. Esse é exatamente o ponto tratado em backup não é sincronização — espelho obedece à origem, e o que obedece à origem cai com ela.

O que vale como "fora do local" quando tudo é nuvem

Traduzindo os três números para primitivas que existem hoje:

Duas mídias vira dois planos de controle. Não é sobre disco versus fita. É sobre a cópia secundária não responder ao mesmo conjunto de APIs, à mesma política de IAM e ao mesmo mecanismo de cobrança da primária. Classe de armazenamento diferente dentro da mesma conta não é segunda mídia: a classe muda preço e latência, não a fronteira de controle.

Fora do local vira, em ordem crescente de independência:

Outra região, mesma conta. Cobre desastre físico regional. Não cobre credencial.
Outra conta do mesmo provedor, com identidade separada. Cobre credencial e automação da conta de produção. Não cobre suspensão do contrato-mãe nem falha de plano de controle do provedor.
Outro provedor, com credencial que não existe na origem. Cobre também o encerramento de conta e o incidente de fornecedor. É o desenho descrito em backup de bucket entre nuvens.

Há um teste simples para saber em que degrau você está. Liste todas as credenciais capazes de apagar a cópia primária. Depois liste as capazes de apagar a secundária. Se houver interseção, o conjunto é uma cópia só para efeito de risco. Faça o mesmo exercício com a fatura: se as duas cópias somem quando um cartão é recusado, elas dependem do mesmo evento.

A cópia secundária também precisa ser gravável sem ser apagável. A identidade que escreve no destino não deve ter permissão de exclusão de objeto nem de versão, e o destino deve carregar retenção imutável — o raciocínio completo está em backup imutável com Object Lock, e o comportamento dos modos de retenção está na documentação do Object Lock no S3.

A variante 3-2-1-1-0

Circula no mercado uma extensão: 3-2-1-1-0 — as três primeiras posições iguais, mais uma cópia offline ou imutável, e zero erros na verificação. Não é norma, não é padrão publicado por organismo técnico e não substitui análise de risco. É um apelido útil para duas práticas que já se sustentam sozinhas.

A posição 1 extra reconhece que "fora do local" deixou de bastar quando o local remoto é alcançável por API. Offline (mídia desconectada) ou imutável (retenção que ninguém remove antes do prazo) são as duas formas de tornar o alcance impossível, e não a mesma coisa.

O 0 é a parte mais negligenciada: verificação com resultado zero erro. Verificar significa ler o dado de volta e comparar com um checksum próprio, não conferir se o objeto existe e tem o tamanho esperado. E significa restaurar de verdade, cronometrado, com as identidades reais — assunto de por que o restore é a parte que ninguém. Acrescente a esse zero a chave de criptografia: cópia independente da qual ninguém consegue extrair o dado é ruído com retenção, tema de quem consegue abrir o seu backup.

O custo da independência

Separar a cópia secundária custa dinheiro, e o custo tem forma previsível. A estrutura típica combina cobrança por requisição (LIST, GET e PUT contam em categorias próprias), cobrança por saída de dados na origem, armazenamento na classe escolhida e, nas classes frias, mínimo de dias faturados e multa por exclusão antecipada. Não publico números aqui porque tabela de preço muda e preço errado é pior que preço nenhum: abra a página de preços do seu provedor, na região exata do bucket, e some os cinco componentes antes de ligar o primeiro ciclo. O que costuma escapar dessa soma está em o que some da conta de um armazenamento barato.

Checklist

Liste as credenciais que alcançam cada cópia. Interseção não nula significa cópia única.
Versionamento e replicação entram como resiliência local, não como as três cópias.
A cópia secundária vive sob identidade que não existe na conta de origem.
Quem escreve no destino não apaga: sem DeleteObject nem DeleteObjectVersion.
Retenção imutável no destino, com prazo maior que o tempo realista de detecção.
Política de ciclo de vida revisada junto com a retenção, nunca em separado.
Chave de criptografia guardada fora do servidor de backup, com cópia testada.
Verificação por checksum próprio e ao menos uma restauração completa cronometrada.
Fatura separada, ou ao menos meio de pagamento que não caia junto com o da produção.

Três cópias que morrem pelo mesmo comando não são três. A regra continua válida; o que mudou foi o que conta como "local".

O NubliVault é o produto de backup da Nublify: empacota milhões de arquivos pequenos e os guarda numa nuvem diferente da de origem. Como funciona · Segurança