Backup na nuvem: estratégias 3-2-1 e recuperação de dados

⏱ 9 min de leitura · Atualizado em maio de 2026

Sexta-feira, 17h. Um colaborador clica num link aparentemente inofensivo. Em 40 minutos, todo o servidor de arquivos da empresa está criptografado por ransomware, e os criminosos pedem resgate em criptomoeda. Nesse momento, a única pergunta que importa é: quanto tempo até a operação voltar? A resposta depende exclusivamente de uma coisa: da qualidade da estratégia de backup na nuvem que estava em pé antes do incidente.

Este artigo cobre como estruturar backup na nuvem do jeito que sobrevive ao primeiro teste real, com regras técnicas reconhecidas pela indústria, escolhas de retenção, proteção contra ransomware e processo de recuperação que de fato funciona. Direcionado a gestores de TI e times de infraestrutura que precisam transformar "fazemos backup" em "temos política de backup que aguenta ataque".

Como funciona o backup na nuvem

Backup na nuvem é o processo de criar cópias de segurança dos dados em servidores remotos, mantidos por provedores especializados, acessíveis pela internet e protegidos por camadas de criptografia, replicação geográfica e controle de acesso.

O fluxo básico funciona em quatro etapas: o agente instalado no ambiente de origem identifica os arquivos a serem copiados, comprime e criptografa esses dados localmente, transmite via internet para o destino na nuvem (frequentemente em múltiplas regiões geograficamente separadas) e mantém a cópia disponível para restauração conforme a política de retenção definida. Toda comunicação acontece sobre conexões cifradas, e os dados ficam criptografados em repouso no destino.

Esse modelo substitui as estratégias antigas de backup em fita magnética ou disco rígido externo por uma operação automatizada, distribuída e auditável. O ganho não é apenas operacional. É uma mudança de paradigma: backup deixa de ser tarefa manual semanal sujeita a esquecimento e passa a ser serviço contínuo monitorado.

Empresa que ainda depende de backup manual em disco externo não tem política de backup. Tem ritual. E ritual não restaura sistema às 18h de uma sexta-feira de ataque.

A Regra 3-2-1 e a Evolução 3-2-1-1-0

Existe uma regra histórica de backup que sobreviveu a todas as transformações da TI: 3-2-1. Ela é o piso da disciplina. Toda política séria de backup parte dela:

• 3 cópias dos dados
  O dado original mais duas copias adicionais. Se uma cópia falha, ainda restam duas. Aritmética simples para reduzir risco de perda total.
• 2 mídias diferentes
  As cópias devem estar em pelo menos dois tipos de armazenamento distintos (por exemplo: um disco local e um storage na nuvem). Falha que afeta um tipo de mídia não afeta o outro.
• 1 cópia offsite
  Pelo menos uma cópia geograficamente afastada do local primário. Incêndio, alagamento ou falha grave no data center principal não destrói essa cópia.

A evolução moderna da regra, recomendada pela maioria dos frameworks de segurança atuais, é o 3-2-1-1-0:

• +1 cópia imutável ou air-gapped
  Pelo menos uma cópia imutável (write-once-read-many) ou desconectada da rede principal. Defesa específica contra ransomware moderno, que mira backups antes de cifrar produção.

• 0 erros nas verificações de restore
  

A diferença entre 3-2-1 e 3-2-1-1-0 é o que separa estratégia da era pré-ransomware da estratégia atual. Empresas que ainda operam apenas com 3-2-1 estão protegidas contra falha de hardware mas vulneráveis a ataque coordenado.

Tipos de backup: full, incremental, diferencial, snapshot

Backup não é operação única. Existem cinco tipos principais que se combinam conforme a política:

Full backup (completo)

Cópia integral de todos os dados do escopo. É o mais demorado e ocupa mais espaço, mas restaura mais rápido e é a base para qualquer outra estratégia. Tipicamente executado em janelas semanais ou mensais.

Incremental

Copia apenas o que mudou desde o último backup, qualquer que seja o tipo (full ou incremental anterior). Rápido e leve, mas a restauração precisa do full mais a sequência completa de incrementais até o ponto desejado.

Diferencial

Copia o que mudou desde o último full backup. Cresce de tamanho ao longo da semana, mas a restauração precisa apenas do full mais o diferencial mais recente. Meio-termo entre full e incremental.

Snapshot

Imagem instantânea do estado do sistema em um momento específico, geralmente em nível de sistema de arquivos ou de storage. Útil para recuperação rápida de estado, especialmente em VMs e containers. Snapshot não substitui backup tradicional porque costuma ficar no mesmo storage do dado original.

Backup sintético

Reconstrução lógica de um full a partir de um full antigo mais incrementais subsequentes, sem precisar copiar todos os dados novamente da produção. Reduz janela de backup e carga em sistemas de produção.

A combinação mais comum em ambientes corporativos sérios é: full semanal, incrementais diários e snapshots em sistemas críticos. Essa estrutura cobre RPO de algumas horas para produção crítica e dias para sistemas menos sensíveis, com custo controlado de armazenamento.

Como decidir frequência e retenção

Duas decisões práticas determinam o custo e a eficácia do backup: com que frequência copiar e por quanto tempo guardar. Os critérios:

Frequência: depende do RPO tolerado

RPO (Recovery Point Objective) define quanta perda de dados a empresa aceita em caso de incidente. Sistema com RPO de 4 horas precisa de backup a cada 4 horas no máximo. Sistema com RPO de 24 horas tolera backup diário. Sistema com RPO de 15 minutos exige replicação contínua, não backup tradicional. RPO precisa ser definido por workload, não pela empresa inteira.

Retenção: depende de regulação e padrões operacionais

O tempo de retenção varia conforme exigências regulatórias e operacionais. Os padrões mais comuns no Brasil:

• Dados financeiros e contábeis: 5 a 10 anos, conforme exigências fiscais e contábeis brasileiras.
• Dados sob LGPD: retenção limitada ao prazo necessário para a finalidade declarada da coleta, com descarte automatizado quando ultrapassada.
• Setor de saúde (ANS, CFM): prontuários eletrônicos com retenção de no mínimo 20 anos.
• Setor financeiro (BCB): retenção específica para registros operacionais, conforme normativos vigentes.
• Backups operacionais (sistemas internos sem regulação específica): 30 a 90 dias é padrão para a maioria dos casos.

Hierarquia de retenção (avô-pai-filho)

Estratégia clássica que continua válida: backups diários mantidos por 30 dias (filhos), backups semanais mantidos por 6 meses (pais), backups mensais mantidos por 1 a 7 anos (avôs). Essa hierarquia entrega granularidade alta no curto prazo e cobertura ampla no longo prazo, com custo de armazenamento controlado.

Imutabilidade: o escudo essencial contra ransomware

Ransomware moderno não se contenta em criptografar produção. As variantes mais sofisticadas dos últimos anos (LockBit, BlackCat/ALPHV, Royal, Black Basta) atacam sistematicamente os backups antes de cifrar a produção, justamente para neutralizar o plano de recuperação. Sem imutabilidade, o atacante criptografa as cópias e a empresa fica sem alternativa além de pagar o resgate.

Imutabilidade significa que, uma vez gravado, o backup não pode ser alterado, deletado ou criptografado por nenhum usuário, incluindo administradores com credenciais comprometidas. As tecnologias que implementam isso:

• Object Lock no S3 (AWS): bloqueio de objetos por período definido, em modo Compliance (intransponível) ou Governance (com exceções administrativas).
• WORM (Write Once Read Many) em storage especializado: hardware projetado para gravação única, com expiração definida.
• Veeam Hardened Repository: repositório Linux com flags imutáveis aplicadas via comandos de baixo nível.
• Air-gapped backup: cópia em storage fisicamente desconectado da rede, acessível apenas em janelas controladas para gravação.

Backup sem imutabilidade em 2026 ´r backup que ainda não foi destruído por ransomware. A pergunta é quando, não se. Implementar imutabilidade não é opcional, é baseline.

Como recuperar dados em incidentes críticos

Recuperação de dados não é o momento de improvisar. As práticas que separam recuperação bem-sucedida de tentativa frustrada:

• Plano documentado e testado: runbook com passo a passo de quem aprova, quem executa, em qual ordem cada sistema volta. Plano que só existe na cabeça de uma pessoa quebra na semana de férias dela.
• Teste de restore mensal em sistemas críticos: a única forma de saber se o backup funciona é restaurando. Backup que nunca foi testado é ficção organizada.
• Ambiente isolado de recuperação: restaurar em ambiente separado evita que o agente de ataque ainda presente na rede ataque os dados restaurados. Especialmente crítico em recuperação pós-ransomware.
• Verificação de integridade pós-restore: hash do dado restaurado deve bater com hash original. Backup pode ter sido corrompido em algum momento sem ninguém perceber.
• Priorização por criticidade: sistemas que voltam primeiro, depois os secundários. Sem priorização, a recuperação vira corrida confusa que atrasa o que importa.
• Comunicação paralela: stakeholders, clientes e reguladores precisam de atualização em paralelo a recuperação técnica. Recuperar bem sem comunicar destrói confiança tanto quanto recuperar mal.
• Automação do que é automatizável: orquestração via código (Terraform, Ansible, Kubernetes operators) acelera recuperação e reduz erro humano em momento de pressão.

Backup e Disaster Recovery: não confundir

Backup e Disaster Recovery são termos que andam juntos e ganham peso diferente. Confundir os dois leva a políticas incompletas ou a investimento mal dimensionado:

Backup

Cópia de segurança dos dados, mantida em local separado do ambiente principal. Foca na preservação do dado em si. Resolve perda granular: arquivo apagado, tabela corrompida, dado sequestrado por ransomware.

Disaster Recovery (DR)

Conjunto completo de procedimentos e infraestrutura para restaurar a operação de TI inteira após um desastre, dentro de RTO e RPO definidos. Inclui backup, mas vai além: site alternativo, runbook de execução, automação de failover, teste regular do plano.

A regra prática: backup e o dado; DR e a operação. Empresa pode ter backup sem DR (restaura arquivos perdidos, mas não restaura operação inteira em 4 horas). Empresa não pode ter DR sem backup, porque DR depende de backup como insumo. Para entender a estratégia completa de continuidade, vale conhecer o guia de Disaster Recovery.

Onde a EVEO entra na sua estratégia de backup

Backup na nuvem entrega valor quando opera sobre infraestrutura confiável, geograficamente distribuída e operada por equipe capaz de garantir restore em momento crítico. A EVEO opera nuvem privada e servidores dedicados em data centers brasileiros, com capacidade para hospedar repositórios de backup com imutabilidade, replicação geográfica e SLA contratual.

Para empresas brasileiras com requisitos de soberania de dados, manter backup em território nacional simplifica conformidade com LGPD, reduz risco jurisdicional e mantém trilha de auditoria sobre acesso aos dados. Casos documentados em histórias de sucesso mostram operações que estruturaram backup com imutabilidade real, teste de restore regular e política de segurança alinhada a regulamentos setoriais.

No fim, a qualidade do backup na nuvem aparece em um momento único e cruel: quando o desastre acontece. Quem investiu na disciplina antes colhe operação restaurada em horas. Quem trata como item de checklist anual descobre que backup não testado não restaura. A diferença entre os dois lados não é tecnologia. É processo, e é disciplina.

Perguntas frequentes

O que é a regra 3-2-1 de backup?

A regra 3-2-1 é o padrão histórico de backup recomendado pela indústria de segurança: manter 3 cópias dos dados, em 2 mídias diferentes, com 1 cópia offsite (geograficamente afastada). É o piso mínimo de qualquer política séria. A versão moderna, recomendada para defesa contra ransomware, é a 3-2-1-1-0: adiciona 1 cópia imutável e exige 0 erros nas verificações de restore.

Backup na nuvem é seguro?

Sim, quando bem implementado. Provedores sérios usam criptografia em trânsito e em repouso, replicação geográfica, controle de acesso granular e auditoria. A segurança depende mais da configuração da política (incluindo imutabilidade e teste de restore) do que da nuvem em si. Backup mal configurado em nuvem boa é tão vulnerável quanto backup mal configurado em qualquer outro lugar.

Qual a diferença entre backup full, incremental e diferencial?

Full copia todos os dados do escopo a cada execução. Incremental copia apenas o que mudou desde o último backup (de qualquer tipo). Diferencial copia o que mudou desde o último full. Full é mais lento e ocupa mais espaço, mas restaura rápido. Incremental é rápido e leve, mas restaurar exige sequência inteira. Diferencial é meio-termo: cresce ao longo da semana, mas restaura com apenas dois arquivos.

Com que frequência devo fazer backup?

Depende do RPO tolerado por workload. Sistema com RPO de 4 horas exige backup a cada 4 horas no máximo. Sistema com RPO de 24 horas tolera backup diário. Sistemas críticos com RPO de minutos precisam de replicação contínua, não backup tradicional. RPO precisa ser definido por workload, não pela empresa inteira, para não desperdiçar em sistemas não críticos nem subinvestir nos críticos.

Backup na nuvem protege contra ransomware?

Apenas se incluir imutabilidade. Backup tradicional na nuvem, sem WORM, Object Lock ou repositório enrijecido, é alvo fácil de ransomware moderno, que mira backups antes de cifrar produção. Implementar cópia imutável ou air-gapped é o que separa backup que sobrevive ao ataque de backup que é neutralizado junto com a produção. A regra 3-2-1-1-0 cobre exatamente esse cenário.