Proteger dados na nuvem exige mais do que copiar arquivos de tempos em tempos. Empresas que operam workloads na AWS, Azure ou GCP precisam de uma estratégia real de backup e recuperação de desastres, com metas claras de tempo de resposta e testes periódicos de restauração. Neste guia, reunimos os fundamentos mais atuais do tema, da regra 3-2-1-1-0 às exigências da LGPD.
O que é a regra 3-2-1 (e por que virou 3-2-1-1-0)
A regra 3-2-1 é conhecida há anos: manter 3 cópias dos dados, em 2 tipos de mídia diferentes, com 1 cópia fora do ambiente principal (offsite). É um bom ponto de partida, mas o cenário de ameaças mudou.
Hoje, o mercado de segurança e resiliência trata como boa prática o modelo 3-2-1-1-0, que adiciona dois elementos:
- Uma cópia imutável ou isolada (air-gapped), que não pode ser alterada ou apagada mesmo por um invasor com acesso administrativo.
- Zero erros nos testes de restauração, ou seja, a garantia de que o backup realmente funciona quando é necessário.
Essa evolução existe porque backups conectados à rede de produção podem ser atingidos junto com os sistemas originais em um ataque. Uma cópia imutável quebra essa cadeia.
RTO e RPO: como definir metas por criticidade
Duas métricas orientam qualquer estratégia de continuidade:
- RPO (Recovery Point Objective): quanto tempo de dados a empresa pode perder. Se o RPO é de 4 horas, o último backup válido não pode ter mais de 4 horas.
- RTO (Recovery Time Objective): quanto tempo o sistema pode ficar indisponível até voltar a operar.
O erro comum é definir essas metas pela ferramenta de backup disponível, em vez de pelo impacto real no negócio. O Google Cloud Architecture Center recomenda o caminho inverso: primeiro avaliar o impacto de cada sistema parado (financeiro, operacional, reputacional) e só depois escolher o padrão de recuperação, seja frio, morno ou quente, de acordo com o orçamento e a criticidade.
Na prática, um sistema de e-commerce que gera receita direta pode exigir RTO de minutos, enquanto um sistema interno de relatórios pode tolerar RTO de um dia. Definir isso por sistema evita gastar demais onde não é necessário e de menos onde é crítico.
Testes de restauração: o passo mais negligenciado
Ter um backup não é o mesmo que conseguir restaurá-lo. Muitas empresas descobrem falhas em seus backups justamente no momento em que mais precisam deles.
O NIST SP 800-53 Rev. 5, na família de controles de Contingency Planning, é direto nesse ponto: o controle CP-9(1) pede testes periódicos de confiabilidade e integridade dos backups, e o CP-9(2) exige a restauração de amostras dos dados como parte dos testes de contingência. A ISO/IEC 27001:2022, no controle 8.13 do Anexo A (Information Backup), segue a mesma linha: a política de backup precisa ser testada regularmente, com verificação antes do próprio processo de cópia e cobertura também para dados em nuvem que não estejam sob gestão interna direta.
Um bom cronograma de testes de restauração inclui:
- Restaurar amostras de dados em ambiente isolado, sem impacto na produção.
- Validar integridade dos arquivos restaurados, não só a existência do backup.
- Documentar o tempo real de restauração e comparar com o RTO definido.
- Repetir o teste após qualquer mudança relevante de infraestrutura.
Ransomware e backups imutáveis: a lição do caso ISAC
Um caso de janeiro de 2025 ilustra bem por que backup sincronizado não é sinônimo de backup seguro. Um instituto de saúde em Brasília, o ISAC, sofreu um ataque atribuído ao grupo LockBit 4.0, que criptografou os discos virtuais da operação e também sobrescreveu os backups que estavam sincronizados com arquivos vazios. O incidente expôs dados de cerca de 500 mil pacientes, e a ANPD abriu processo sancionador em julho de 2026 por ausência de medidas técnicas adequadas. Vale destacar que o processo segue em apuração, e o caso deve ser lido como exemplo do risco, não como conclusão definitiva sobre responsabilidades.
A lição prática é clara: se o backup está permanentemente conectado e sincronizado com o ambiente de produção, ele pode ser atingido pelo mesmo ataque. É exatamente esse ponto que o "1" adicional do 3-2-1-1-0 resolve, com uma cópia imutável ou fisicamente isolada.
Provedores de nuvem já respondem a esse cenário. Em 2025, o AWS Backup reforçou recursos voltados a resiliência contra ransomware, como vaults logicamente isolados e imutáveis por padrão, chaves de criptografia gerenciadas pelo cliente, aprovação de múltiplas partes para acessos considerados críticos, integração com o Amazon GuardDuty para varredura de malware nos backups e restauração em nível de item individual.
LGPD, ANPD e comunicação de incidentes
A LGPD não usa a palavra "backup" no texto da lei, mas o artigo 46 exige medidas técnicas e administrativas capazes de proteger dados pessoais contra perda, destruição e situações de indisponibilidade. Isso coloca a estratégia de backup e recuperação diretamente dentro do escopo da lei.
Um ponto frequentemente esquecido por times técnicos: indisponibilidade de dados também pode configurar um incidente de segurança sujeito a comunicação à ANPD. A Resolução CD/ANPD nº 15/2024 estabelece que, diante de um incidente com risco relevante, como os que envolvem dados sensíveis, dados de crianças, informações financeiras, credenciais de autenticação ou tratamento em larga escala, o controlador deve comunicar a ANPD e os titulares em até 3 dias úteis após ter ciência do ocorrido.
Isso significa que o plano de recuperação de desastres não deve tratar apenas do lado técnico da restauração. Ele precisa prever também quem aciona o time jurídico, como o incidente é documentado e como a comunicação aos titulares e à ANPD é feita dentro do prazo.
Backup e DR nas três nuvens: AWS, Azure e GCP
Cada provedor oferece caminhos nativos para backup e recuperação, com abordagens um pouco diferentes:
- AWS: o AWS Well-Architected Framework define quatro estratégias de disaster recovery em ordem crescente de custo e complexidade: Backup and Restore, Pilot Light, Warm Standby e Multi-Site Active/Active. A escolha depende do RTO e RPO definidos para cada workload.
- Azure: o Well-Architected Framework, no pilar de Reliability, recomenda armazenamento com replicação geográfica com zona (GZRS) para recuperação entre regiões, réplica síncrona entre zonas para dados críticos e réplica assíncrona entre regiões para dados de menor prioridade, sempre com runbooks de recuperação testados.
- GCP: o Google Cloud Architecture Center reforça o mesmo princípio central deste artigo: definir RTO e RPO primeiro, a partir do impacto no negócio, e só então escolher entre os padrões de recuperação frio, morno ou quente.
Em ambientes híbridos ou multicloud, manter uma cópia local ou em outro provedor além da nuvem principal também ajuda a reduzir o RTO e a cumprir os requisitos da LGPD, já que reduz a dependência de um único ponto de falha.
Checklist final
Para alinhar a estratégia de backup às normas e frameworks vigentes, vale revisar:
- A política de backup segue o modelo 3-2-1-1-0, com cópia imutável ou isolada da rede de produção.
- RTO e RPO estão definidos por sistema, com base em impacto no negócio, e não na ferramenta disponível.
- Testes de restauração acontecem periodicamente, com amostras reais e resultado documentado, alinhados ao controle 8.13 da ISO/IEC 27001:2022 e aos controles CP-9 do NIST SP 800-53.
- A cobertura de backup inclui dados em nuvem, mesmo os que não estão sob gestão interna direta.
- Existe um fluxo definido para comunicação de incidentes à ANPD e aos titulares dentro do prazo de 3 dias úteis previsto na Resolução CD/ANPD nº 15/2024.
- O Control 11 do CIS Critical Security Controls v8, de recuperação de dados, está refletido no processo, com backups automatizados e isolamento das cópias.
Backup e recuperação de desastres não são um projeto de uma única vez, mas um processo contínuo de definição de metas, testes e ajustes. A Cloud Minds Trusted acompanha empresas na construção dessa estratégia, da arquitetura de backups imutáveis na nuvem até o alinhamento com LGPD, ISO 27001 e NIST. Se sua empresa quer revisar sua postura de resiliência, converse com a Cloud Minds Trusted.