Estratégia de Backup Cloud: Guia Abrangente

Uma estratégia de backup na nuvem que funciona segue a regra 3-2-1: três cópias dos dados, em dois tipos de suporte diferentes, com uma cópia fora do local — na prática isso significa uma cópia primária (armazenamento de produção), um backup local (NAS ou disco externo), e pelo menos uma camada cloud (Backblaze B2, AWS S3 Glacier Deep Archive ou Wasabi). Acrescente imutabilidade via object lock, encripte do lado do cliente com AES-256 antes do carregamento, automatize via restic ou Borg durante a noite e — este é o passo que a maioria das equipas ignora — teste um restauro completo trimestralmente. Sem um restauro testado, tem esperança, não um backup.

Por que a Regra 3-2-1 Ainda Faz Sentido em 2026

A regra 3-2-1 remonta à fotografia analógica, mas a matemática não mudou. Três cópias dão-lhe redundância suficiente para que qualquer falha singular (crash de disco, ransomware, rm -rf acidental) deixe duas cópias intactas. Dois tipos de suporte cobrem as falhas sistemáticas — uma versão de firmware com defeito que inutiliza um modelo completo de SSD, ou uma interrupção de uma região de um fornecedor cloud. Uma cópia fora do local protege contra o evento ao nível do edifício: incêndio, inundação, roubo, ou o camião de mudanças a bater no seu rack.

Existem variantes modernizadas. A 3-2-1-1-0 acrescenta uma cópia imutável e exige zero erros nos testes de restauro. A 4-3-2 (usada por muitos MSPs) mantém quatro cópias e dois fornecedores cloud. Escolha uma, documente-a e cumpra-a. O número específico importa menos do que a disciplina.

Escolher Camadas de Armazenamento para Custo vs. Velocidade de Recuperação

Os fornecedores cloud oferecem classes de armazenamento a preços dramaticamente diferentes:

| Camada | Custo por GB/mês | Latência do primeiro byte | Taxa de egress | |--------|-----------------|--------------------------|----------------| | S3 Standard | 0,023 EUR | milissegundos | 0,09 EUR/GB | | S3 Glacier Instant | 0,004 EUR | milissegundos | 0,03 EUR/GB | | S3 Glacier Flexible | 0,0036 EUR | 3-5 minutos | 0,02 EUR/GB | | S3 Glacier Deep Archive | 0,00099 EUR | 12 horas | 0,02 EUR/GB | | Backblaze B2 | 0,006 EUR | milissegundos | 0,01 EUR/GB | | Wasabi | 0,0069 EUR | milissegundos | gratuito (até 1x armazenado/mês) | | Cloudflare R2 | 0,015 EUR | milissegundos | gratuito |

Para backup especificamente, o Glacier Deep Archive atinge cerca de 1 EUR por TB por mês, mas a latência de restauro significa que não pode usá-lo para "ó não, apaguei o ficheiro de ontem." Uma abordagem de duas camadas funciona melhor: backups recentes numa camada quente (B2 ou R2), migrando os de mais de 30 dias para Glacier Deep Archive via política de ciclo de vida.

A Regra 3-2-1 em Termos Concretos

Um exemplo de pilha para um conjunto de trabalho de 2 TB:

Produção: portáteis, servidores, dados SaaS (cópia primária)
Local: NAS com ZFS e snapshots, 4 TB utilizáveis, espelhado semanalmente para um disco USB externo guardado num cofre resistente ao fogo
Cloud quente: bucket Backblaze B2 com restic, incremental noturno, retenção de 90 dias a ~12 EUR/mês para 2 TB
Cloud frio: S3 Glacier Deep Archive via política de ciclo de vida, snapshots anuais, retenção de 7 anos a ~24 EUR/ano para 2 TB

Custo mensal total: menos de 20 EUR para cobertura 3-2-1 completa com um histórico de sete anos. Mais barato do que um portátil de substituição.

Automatizar Backups com Ferramentas Fiáveis

O restic é a escolha padrão para backups incrementais encriptados para armazenamento de objetos. Deduplica, comprime, encripta com AES-256-CTR mais Poly1305, e suporta B2, S3, Azure, GCS e SFTP nativamente:

restic -r b2:hexa-backups:production init
restic -r b2:hexa-backups:production backup /var/data \
  --exclude-file=/etc/restic/exclude.txt \
  --tag nightly
restic -r b2:hexa-backups:production forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Execute-o durante a noite via systemd timer ou cron, com a palavra-passe do repositório num ficheiro legível apenas pelo root. O Borg Backup é uma excelente alternativa, particularmente se precisar de suporte para repositórios locais; o Kopia é mais recente e tem uma interface mais amigável.

Para estações de trabalho Windows, o Duplicati ou o Windows File History integrado mais um destino cloud cobre o essencial. Para Macs, Time Machine para um NAS local mais Arq Backup para Backblaze B2 é uma combinação testada em batalha.

Tornar os Backups Imutáveis Contra Ransomware

O ransomware que encripta os dados de produção tentará encriptar os backups também. O object lock impede isso. Tanto o AWS S3 como o Backblaze B2 suportam "modo de conformidade" onde nem mesmo a conta root pode eliminar objetos até o período de retenção expirar:

aws s3api put-object-lock-configuration \
  --bucket backup-immutable \
  --object-lock-configuration '{
    "ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}
  }'

Durante 30 dias após o carregamento, ninguém — incluindo um administrador comprometido — pode eliminar o backup. Combine isto com versionamento, MFA-delete e um perfil IAM que pode escrever mas não sobrescrever, e fechou o caminho dominante do ransomware.

Encriptar do Lado do Cliente Antes do Carregamento

Mesmo com encriptação do lado do fornecedor (SSE-KMS), o seu fornecedor cloud detém as chaves, o que significa que pedidos de intimação judicial podem compelir a desencriptação. Para dados sensíveis, encripte antes de os bytes saírem da sua rede. O restic faz isto automaticamente; para ficheiros ad hoc, o age é uma boa opção:

age -r age1xyz... -o archive.tar.gz.age archive.tar.gz
aws s3 cp archive.tar.gz.age s3://backups/

Guarde a chave privada age no 1Password ou numa chave de segurança física como a YubiKey. Faça cópia de segurança da própria chave em papel, encriptada com uma frase-passe, numa caixa de cofre bancário. Uma chave de encriptação perdida é tão catastrófica quanto dados perdidos.

O Teste de Recuperação É o Backup

Trimestralmente, escolha um ficheiro ou servidor aleatório e restaure-o de ponta a ponta para um ambiente limpo. Meça:

RTO (objetivo de tempo de recuperação): desde a decisão até ao restauro concluído
RPO (objetivo de ponto de recuperação): quanta informação foi perdida (horas, dias)
Integridade: os bytes restaurados correspondem ao hash original?

Um exemplo real: uma equipa que executava backups noturnos para o S3 Glacier Deep Archive descobriu durante o primeiro teste de restauro que o aprovisionamento das permissões de restauro mais a espera de 12 horas de recuperação tornavam o RTO de 18 horas quando o negócio precisava de 4. Migraram a retenção ativa para o Glacier Flexible (recuperação em 3-5 minutos) e mantiveram o Deep Archive apenas para histórico de conformidade. Esse teste poupou-lhes aprender a lição durante um incidente real.

Documente o runbook à medida que avança: comandos, credenciais, frases-passe de desencriptação, quem pode autorizar um restauro. Teste-o num portátil limpo para confirmar que o runbook funciona sem o seu ambiente local.

Requisitos Regulamentares de Retenção

Vários regulamentos especificam retenção mínima:

RGPD: sem número fixo; reter apenas durante o necessário para as finalidades declaradas — a CNPD em Portugal orienta a aplicação
HIPAA: 6 anos para registos de auditoria e políticas
SOX: 7 anos para registos financeiros
PCI DSS 4.0: 1 ano para registos de auditoria, 3 meses "imediatamente disponíveis"
FINRA 17a-4: 3-6 anos, exigido armazenamento compatível com WORM

Etiquete os backups com metadados de retenção e aplique via políticas de ciclo de vida para não guardar dados por mais tempo do que o necessário (um problema do RGPD) nem por menos tempo do que o exigido (um problema SOX).

Monitorização e Alertas

Backups que falham silenciosamente são piores do que não ter backups. Cada trabalho restic ou Borg deve emitir métricas: duração, bytes transferidos, ficheiros alterados, sucesso/falha. Envie para Prometheus, Datadog ou um registo cron simples monitorizado por uma ferramenta do tipo Dead Man's Snitch que alerta quando o heartbeat esperado não chega. O modo de falha que está a tentar detetar é "os backups estão quebrados há 90 dias e ninguém reparou."

Alerte sobre: falha no trabalho, trabalho ignorado, corrupção do repositório (restic check), alteração de tamanho incomum (perda de dados ou crescimento inesperado) e falha no teste de restauro.

O HexaTransfer não é uma ferramenta de backup — destina-se a transferências encriptadas únicas — mas os mesmos princípios de cifração ponta a ponta aplicam-se quando está a enviar um arquivo de backup a um colega. Experimente em hexatransfer.com — gratuito, sem conta necessária, máximo de 10 GB.

Da Estratégia à Disciplina

Uma estratégia de backup na nuvem vive ou morre pela disciplina mais do que pela arquitetura. Execuções noturnas, testes de restauro trimestrais, revisões anuais do runbook, retenção imutável e encriptação do lado do cliente não são glamorosas, mas são a diferença entre "tínhamos um backup" e "conseguimos recuperar." Escreva o que faz, automatize o que conseguir, teste o que não consegue automatizar, e mantenha o custo mensal total baixo o suficiente para que ninguém nas finanças alguma vez lhe peça para o reduzir. Barato mais aborrecido supera caro mais inteligente em todas as situações.