Backup na nuvem: estrategias 3-2-1 e recuperacao de dados

⏱ 9 min de leitura · Atualizado em abril 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 copias de seguranca dos dados em servidores remotos, mantidos por provedores especializados, acessiveis pela internet e protegidos por camadas de criptografia, replicacao geografica e controle de acesso.

O fluxo basico 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 multiplas regioes geograficamente separadas) e mantem a copia disponivel para restauracao conforme a politica de retencao definida. Toda comunicacao acontece sobre conexoes cifradas, e os dados ficam criptografados em repouso no destino.

Esse modelo substitui as estrategias antigas de backup em fita magnetica ou disco rigido externo por uma operacao automatizada, distribuida e auditavel. O ganho nao e apenas operacional. E uma mudanca de paradigma: backup deixa de ser tarefa manual semanal sujeita a esquecimento e passa a ser servico continuo monitorado.

Empresa que ainda depende de backup manual em disco externo nao tem politica de backup. Tem ritual. E ritual nao restaura sistema as 18h de uma sexta-feira de ataque.

A regra 3-2-1 e a evolucao 3-2-1-1-0

Existe uma regra historica de backup que sobreviveu a todas as transformacoes da TI: 3-2-1. Ela e o piso da disciplina. Toda politica seria de backup parte dela:

3 copias dos dados

O dado original mais duas copias adicionais. Se uma copia falha, ainda restam duas. Aritmetica simples para reduzir risco de perda total.

2 midias diferentes

As copias 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 midia nao afeta o outro.

1 copia offsite

Pelo menos uma copia geograficamente afastada do local primario. Incendio, alagamento ou falha grave no data center principal nao destrói essa copia.

A evolucao moderna da regra, recomendada pela maioria dos frameworks de seguranca atuais, e o 3-2-1-1-0:

+1 copia imutavel ou air-gapped

Pelo menos uma copia imutavel (write-once-read-many) ou desconectada da rede principal. Defesa especifica contra ransomware moderno, que mira backups antes de cifrar producao.

0 erros nas verificacoes de restore

Zero erros nas validacoes de integridade e nos testes de restore. Backup que nao passa em teste de restore nao e backup. E arquivo lacrado de uso desconhecido.

A diferenca entre 3-2-1 e 3-2-1-1-0 e o que separa estrategia da era pre-ransomware da estrategia atual. Empresas que ainda operam apenas com 3-2-1 estao protegidas contra falha de hardware mas vulneraveis a ataque coordenado.

Tipos de backup: full, incremental, diferencial, snapshot

Backup nao e operacao unica. Existem cinco tipos principais que se combinam conforme a politica:

Full backup (completo)

Copia integral de todos os dados do escopo. E o mais demorado e ocupa mais espaco, mas restaura mais rapido e e a base para qualquer outra estrategia. Tipicamente executado em janelas semanais ou mensais.

Incremental

Copia apenas o que mudou desde o ultimo backup, qualquer que seja o tipo (full ou incremental anterior). Rapido e leve, mas a restauracao precisa do full mais a sequencia completa de incrementais ate o ponto desejado.

Diferencial

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

Snapshot

Imagem instantanea do estado do sistema em um momento especifico, geralmente em nivel de sistema de arquivos ou de storage. Util para recuperacao rapida de estado, especialmente em VMs e containers. Snapshot nao substitui backup tradicional porque costuma ficar no mesmo storage do dado original.

Backup sintetico

Reconstrucao logica de um full a partir de um full antigo mais incrementais subsequentes, sem precisar copiar todos os dados novamente da producao. Reduz janela de backup e carga em sistemas de producao.

A combinacao mais comum em ambientes corporativos serios e: full semanal, incrementais diarios e snapshots horarios em sistemas criticos. Essa estrutura cobre RPO de algumas horas para producao critica e dias para sistemas menos sensiveis, com custo controlado de armazenamento.

Como decidir frequencia e retencao

Duas decisoes praticas determinam o custo e a eficacia do backup: com que frequencia copiar e por quanto tempo guardar. Os criterios:

Frequencia: 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 maximo. Sistema com RPO de 24 horas tolera backup diario. Sistema com RPO de 15 minutos exige replicacao continua, nao backup tradicional. RPO precisa ser definido por workload, nao pela empresa inteira.

Retencao: depende de regulacao e padroes operacionais

O tempo de retencao varia conforme exigencias regulatorias e operacionais. Os padroes mais comuns no Brasil:

• Dados financeiros e contabeis: 5 a 10 anos, conforme exigencias fiscais e contabeis brasileiras.
• Dados sob LGPD: retencao limitada ao prazo necessario para a finalidade declarada da coleta, com descarte automatizado quando ultrapassada.
• Setor de saude (ANS, CFM): prontuarios eletronicos com retencao de no minimo 20 anos.
• Setor financeiro (BCB): retencao especifica para registros operacionais, conforme normativos vigentes.
• Backups operacionais (sistemas internos sem regulacao especifica): 30 a 90 dias e padrao para a maioria dos casos.

Hierarquia de retencao (avo-pai-filho)

Estrategia classica que continua valida: backups diarios mantidos por 30 dias (filhos), backups semanais mantidos por 6 meses (pais), backups mensais mantidos por 1 a 7 anos (avos). 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 nao se contenta em criptografar producao. As variantes mais sofisticadas dos ultimos anos (LockBit, BlackCat/ALPHV, Royal, Black Basta) atacam sistematicamente os backups antes de cifrar a producao, justamente para neutralizar o plano de recuperacao. Sem imutabilidade, o atacante criptografa as copias e a empresa fica sem alternativa alem de pagar o resgate.

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

• Object Lock no S3 (AWS): bloqueio de objetos por periodo definido, em modo Compliance (intransponivel) ou Governance (com excecoes administrativas).
• WORM (Write Once Read Many) em storage especializado: hardware projetado para gravacao unica, com expiracao definida.
• Veeam Hardened Repository: repositorio Linux com flags imutaveis aplicadas via comandos de baixo nivel.
• Air-gapped backup: copia em storage fisicamente desconectado da rede, acessivel apenas em janelas controladas para gravacao.

Backup sem imutabilidade em 2026 e backup que ainda nao foi destruido por ransomware. A pergunta e quando, nao se. Implementar imutabilidade nao e opcional, e baseline.

Como recuperar dados em incidentes criticos

Recuperacao de dados nao e o momento de improvisar. As praticas que separam recuperacao 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 so existe na cabeca de uma pessoa quebra na semana de ferias dela.
• Teste de restore mensal em sistemas criticos: a unica forma de saber se o backup funciona e restaurando. Backup que nunca foi testado e ficcao organizada.
• Ambiente isolado de recuperacao: restaurar em ambiente separado evita que o agente de ataque ainda presente na rede ataque os dados restaurados. Especialmente critico em recuperacao pos-ransomware.
• Verificacao de integridade pos-restore: hash do dado restaurado deve bater com hash original. Backup pode ter sido corrompido em algum momento sem ninguem perceber.
• Priorizacao por criticidade: sistemas que voltam primeiro, depois os secundarios. Sem priorizacao, a recuperacao vira corrida confusa que atrasa o que importa.
• Comunicacao paralela: stakeholders, clientes e reguladores precisam de atualizacao em paralelo a recuperacao tecnica. Recuperar bem sem comunicar destroi confianca tanto quanto recuperar mal.
• Automacao do que e automatizavel: orquestracao via codigo (Terraform, Ansible, Kubernetes operators) acelera recuperacao e reduz erro humano em momento de pressao.

Backup e Disaster Recovery: nao confundir

Backup e Disaster Recovery sao termos que andam juntos e ganham peso diferente. Confundir os dois leva a politicas incompletas ou a investimento mal dimensionado:

Backup

Copia de seguranca dos dados, mantida em local separado do ambiente principal. Foca na preservacao 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 operacao de TI inteira apos um desastre, dentro de RTO e RPO definidos. Inclui backup, mas vai alem: site alternativo, runbook de execucao, automacao de failover, teste regular do plano.

A regra pratica: backup e o dado; DR e a operacao. Empresa pode ter backup sem DR (restaura arquivos perdidos, mas nao restaura operacao inteira em 4 horas). Empresa nao pode ter DR sem backup, porque DR depende de backup como insumo. Para entender a estrategia completa de continuidade, vale conhecer o guia de Disaster Recovery.

Onde a EVEO entra na sua estrategia de backup

Backup na nuvem entrega valor quando opera sobre infraestrutura confiavel, geograficamente distribuida e operada por equipe capaz de garantir restore em momento critico. A EVEO opera nuvem privada e servidores dedicados em data centers brasileiros, com capacidade para hospedar repositorios de backup com imutabilidade, replicacao geografica e SLA contratual.

Para empresas brasileiras com requisitos de soberania de dado, manter backup em territorio nacional simplifica conformidade com LGPD, reduz risco jurisdicional e mantem trilha de auditoria sobre acesso aos dados. Casos documentados em historias de sucesso mostram operacoes que estruturaram backup com imutabilidade real, teste de restore regular e politica de seguranca alinhada a regulamentos setoriais.

No fim, a qualidade do backup na nuvem aparece em um momento unico e cruel: quando o desastre acontece. Quem investiu na disciplina antes colhe operacao restaurada em horas. Quem trata como item de checklist anual descobre que backup nao testado nao restaura. A diferenca entre os dois lados nao e tecnologia. E processo, e e disciplina.

Perguntas frequentes

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

A regra 3-2-1 e o padrao historico de backup recomendado pela industria de seguranca: manter 3 copias dos dados, em 2 midias diferentes, com 1 copia offsite (geograficamente afastada). E o piso minimo de qualquer politica seria. A versao moderna, recomendada para defesa contra ransomware, e a 3-2-1-1-0: adiciona 1 copia imutavel e exige 0 erros nas verificacoes de restore.

Backup na nuvem e seguro?

Sim, quando bem implementado. Provedores serios usam criptografia em transito e em repouso, replicacao geografica, controle de acesso granular e auditoria. A seguranca depende mais da configuracao da politica (incluindo imutabilidade e teste de restore) do que da nuvem em si. Backup mal configurado em nuvem boa e tao vulneravel quanto backup mal configurado em qualquer outro lugar.

Qual a diferenca entre backup full, incremental e diferencial?

Full copia todos os dados do escopo a cada execucao. Incremental copia apenas o que mudou desde o ultimo backup (de qualquer tipo). Diferencial copia o que mudou desde o ultimo full. Full e mais lento e ocupa mais espaco, mas restaura rapido. Incremental e rapido e leve, mas restaurar exige sequencia inteira. Diferencial e meio-termo: cresce ao longo da semana, mas restaura com apenas dois arquivos.

Com que frequencia devo fazer backup?

Depende do RPO tolerado por workload. Sistema com RPO de 4 horas exige backup a cada 4 horas no maximo. Sistema com RPO de 24 horas tolera backup diario. Sistemas criticos com RPO de minutos precisam de replicacao continua, nao backup tradicional. RPO precisa ser definido por workload, nao pela empresa inteira, para nao desperdicar em sistemas nao criticos nem subinvestir nos criticos.

Backup na nuvem protege contra ransomware?

Apenas se incluir imutabilidade. Backup tradicional na nuvem, sem WORM, Object Lock ou repositorio enrijecido, e alvo facil de ransomware moderno, que mira backups antes de cifrar producao. Implementar copia imutavel ou air-gapped e o que separa backup que sobrevive ao ataque de backup que e neutralizado junto com a producao. A regra 3-2-1-1-0 cobre exatamente esse cenario.