Regra 3-2-1(-1-0)

1. Origem

A regra é comumente atribuída a Peter Krogh, fotógrafo e autor, que a popularizou em seu livro The DAM Book (Digital Asset Management) nos anos 2000. O contexto original era a proteção de acervos fotográficos digitais — um disco rígido único que falhava representava a perda definitiva de todo o trabalho. A simplicidade da fórmula (3 cópias, 2 mídias, 1 off‑site) fez com que ela fosse adotada mundialmente como boa prática mínima, muito além da fotografia.

2. Por que a regra funciona — redução de pontos únicos de falha

Cada número da regra protege contra um tipo específico de ponto único de falha:

Essa abordagem de camadas garante que, para uma única causa, nunca se perdem todas as cópias simultaneamente. É o mesmo princípio de defesa em profundidade usado em segurança da informação.

3. A regra original — 3-2-1

• 3 cópias dos dados no total (o original + 2 backups)
• 2 mídias/tipos diferentes de armazenamento (ex.: disco + nuvem)
• 1 cópia fora do local físico principal (off‑site)

Durante quase duas décadas, esse tripé foi suficiente para a maioria dos cenários. Com a explosão do ransomware direcionado, a indústria percebeu que as 3 cópias podem estar igualmente vulneráveis se todas forem acessíveis pela mesma rede e credencial.

4. Evolução para 3-2-1-1-0

A extensão foi formalizada publicamente pela Veeam (~2021) e alinhada ao guia #StopRansomware da CISA (Cybersecurity and Infrastructure Security Agency, EUA). Ela adiciona duas camadas de proteção:

• +1 — uma cópia offline, air‑gapped ou imutável, impossível de alterar ou apagar mesmo com credenciais de administrador comprometidas.
• 0 — zero erros nos backups, garantido por testes de restauração reais e periódicos, não apenas pela ausência de mensagens de erro na execução.

O “+1” é a diferença entre ter backup e ter um backup que um ransomware não consegue destruir. O “0” é a diferença entre achar que tem backup e ter certeza — o que também atende ao requisito de accountability da LGPD.

5. Air‑gap físico vs. imutabilidade lógica

O “+1” pode ser implementado de duas formas principais, dependendo da ferramenta e do orçamento:

A escolha depende do perfil do ISP: fitas exigem operação manual, mas são imbatíveis em air‑gap; imutabilidade lógica é mais prática, mas depende da configuração correta e da confiança no provedor.

6. Como aplicar num ISP real — servidor FreeRADIUS + MySQL

Mapeamento prático da regra para o cenário mais comum de ISP brasileiro:

A fita LTO (LTO‑8 armazena até 12 TB) ainda é uma escolha viável em 2026 exatamente pelo air‑gap físico genuíno. Trade‑off: operação manual e menor velocidade de restauração.

7. A regra define “onde”, mas não “quando” — o papel do RTO e RPO

A regra 3‑2‑1‑1‑0 garante que você tenha cópias íntegras e seguras, mas não responde duas perguntas igualmente críticas:

• Com que frequência o backup é feito? → isso define o RPO — quantos dados você aceita perder.
• Em quanto tempo você consegue restaurar? → isso define o RTO — quanto tempo o serviço fica indisponível.

Exemplo: um backup diário off‑site atende 3‑2‑1‑1‑0, mas se o RPO exigido para o banco RADIUS é de 1 hora, você precisa de incrementais horários. Se o RTO é de 30 minutos, restaurar um volume de 200 GB de um bucket S3 lento não vai atender — é preciso backup local rápido.

8. Script de verificação periódica + restauração de teste

O script abaixo implementa o “0” da regra: ele confere cada camada e executa uma restauração real, comparando o conteúdo restaurado com o original. Deve ser agendado semanalmente no cron.

#!/bin/bash
# verificacao-321.sh — checa as camadas da regra e testa restauração
# Agendamento sugerido: 0 6 * * 1 /usr/local/bin/verificacao-321.sh

set -euo pipefail
LOG="/var/log/backup-verificacao.log"
DATA=$(date '+%Y-%m-%d %H:%M:%S')
FALHAS=0

echo "[$DATA] Iniciando verificação 3-2-1-1-0" >> "$LOG"

# ── 1) Cópia local (2ª cópia) ──
ULTIMO_LOCAL=$(restic snapshots --latest 1 --json | jq -r '.[0].time' 2>/dev/null || echo "")
if [ -z "$ULTIMO_LOCAL" ]; then
    echo "[$DATA] FALHA: sem snapshot local recente" >> "$LOG"
    FALHAS=$((FALHAS+1))
fi

# ── 2) Cópia off‑site (3ª cópia) ──
IDADE_S3=$(aws s3api head-object --bucket backup-isp --key latest.tar.gz \
    --query 'LastModified' --output text 2>/dev/null || echo "")
if [ -z "$IDADE_S3" ]; then
    echo "[$DATA] FALHA: cópia off‑site não encontrada" >> "$LOG"
    FALHAS=$((FALHAS+1))
fi

# ── 3) Imutabilidade (+1) — Object Lock ativo? ──
LOCK_STATUS=$(aws s3api get-object-lock-configuration --bucket backup-isp \
    --query 'ObjectLockConfiguration.ObjectLockEnabled' --output text 2>/dev/null || echo "DISABLED")
if [ "$LOCK_STATUS" != "Enabled" ]; then
    echo "[$DATA] ALERTA CRÍTICO: Object Lock desabilitado — backup vulnerável" >> "$LOG"
    FALHAS=$((FALHAS+1))
fi

# ── 4) Teste real de restauração (0) ──
RESTORE_DIR="/tmp/teste-restauracao-$(date +%s)"
mkdir -p "$RESTORE_DIR"
if restic restore latest --target "$RESTORE_DIR" 2>>"$LOG"; then
    if diff -rq /var/lib/mysql-dump "$RESTORE_DIR/var/lib/mysql-dump" > /dev/null 2>&1; then
        echo "[$DATA] OK: restauração de teste íntegra" >> "$LOG"
    else
        echo "[$DATA] FALHA: dados restaurados diferentes do original" >> "$LOG"
        FALHAS=$((FALHAS+1))
    fi
else
    echo "[$DATA] FALHA: comando de restauração retornou erro" >> "$LOG"
    FALHAS=$((FALHAS+1))
fi
rm -rf "$RESTORE_DIR"

# ── Resultado final ──
if [ "$FALHAS" -gt 0 ]; then
    echo "[$DATA] VERIFICAÇÃO CONCLUÍDA COM $FALHAS FALHA(S)" >> "$LOG"
    exit 1
fi
echo "[$DATA] VERIFICAÇÃO OK — regra 3-2-1-1-0 atendida" >> "$LOG"
exit 0

Adaptação para outras ferramentas: se você usa Borg, substitua os comandos restic por borg; para Bacula, use bconsole. O princípio é sempre o mesmo: restaurar e comparar, não apenas confiar na mensagem de “job concluído”.

9. Checklist operacional

10. Mitos comuns — o que NÃO é backup

11. Exemplo prático de dimensionamento para ISP

Suponha um ISP com 5 servidores críticos: RADIUS, DNS, portal de cliente, billing e monitoramento. Cada um gera, após deduplicação e compressão, uma média de 200 MB por dia de dados de backup incremental.

Nesse cenário, a nuvem é conveniente e barata para off‑site, enquanto a fita pode ser usada para o air‑gap mensal. O custo total mensal é irrisório perto do risco de perder dados de bilhetagem — que podem gerar multas, processos e danos reputacionais.

12. Referências

• Peter Krogh — The DAM Book (Digital Asset Management), popularização da regra 3‑2‑1.
• CISA — #StopRansomware Guide (guia oficial de resposta a ransomware).
• Veeam — formalização pública da extensão 3‑2‑1‑1‑0 (~2021).
• NIST SP 800‑34 Rev. 1 — Contingency Planning Guide (planejamento de contingência).
• NIST SP 800‑209 — Security Guidelines for Storage Infrastructure (imutabilidade).
• ABNT NBR ISO/IEC 27002 — controle 12.3 (cópias de segurança).
• Páginas relacionadas: LGPD e Backup, RTO, RPO, restic, Borg, Bacula.

Conteúdo técnico independente. Nenhum trecho é cópia literal das fontes citadas.