Ter uma cópia dos arquivos não significa, por si só, que a empresa conseguirá retomar a operação. A recuperação depende de cópias acessíveis, íntegras e suficientemente isoladas — além de um procedimento que alguém já tenha executado. Em um incidente de ransomware, a diferença entre backup e continuidade aparece justamente na hora de restaurar.
Este guia ajuda pequenas e médias empresas a transformar o backup em um plano testável: o que copiar, como reduzir o risco de a cópia ser atingida junto com o ambiente principal e como medir se a recuperação atende à necessidade do negócio.
Backup é uma cópia; recuperação é um processo
Um backup pode existir e ainda falhar como estratégia: estar desatualizado, corrompido, incompleto ou depender de credenciais indisponíveis durante a crise. A CISA recomenda manter cópias críticas offline e criptografadas e testar regularmente sua disponibilidade e integridade em cenários de recuperação. A agência também alerta que atacantes podem procurar e apagar backups acessíveis na rede.
Por isso, considere a cadeia completa: identificar dados e sistemas essenciais, preservar cópias independentes, documentar prioridades e validar restaurações. Para serviços em nuvem, isso também significa conferir as permissões e a separação entre a conta de produção e o ambiente que armazena os backups.
Use a regra 3-2-1 como ponto de partida — não como garantia
A regra 3-2-1 propõe manter três cópias dos dados, em pelo menos dois tipos de mídia, com uma cópia fora do local principal. Ela ajuda a evitar que uma falha física ou lógica única elimine todas as versões. Contra ransomware, porém, a contagem só é útil se uma cópia não puder ser alterada ou apagada pelo mesmo acesso comprometido.
- Três cópias: conte a cópia de produção e duas cópias de backup, deixando explícito o que cada uma protege.
- Duas mídias ou ambientes distintos: reduza dependências comuns, como o mesmo equipamento, credencial administrativa ou rede.
- Uma cópia fora do ambiente principal: mantenha uma cópia offline ou com acesso fortemente segregado, conforme os requisitos técnicos e operacionais.
A regra é uma referência de desenho, não uma certificação de segurança. Retenção, criptografia, imutabilidade e localização precisam ser avaliadas junto a custos, obrigações legais e capacidade real de restauração. A própria CISA recomenda cautela com armazenamento imutável: configuração inadequada pode gerar custos relevantes e certas opções podem não atender a determinados requisitos regulatórios.
Defina RPO e RTO a partir do impacto no negócio
RPO (objetivo de ponto de recuperação) indica quanto de dado recente a operação aceita perder, medido como intervalo de tempo. RTO (objetivo de tempo de recuperação) indica por quanto tempo o serviço pode ficar indisponível antes de causar impacto inaceitável. Eles não são promessas automáticas do backup: são metas que precisam ser confrontadas com a frequência das cópias, o volume a restaurar, a largura de banda, as dependências e a equipe disponível.
Exemplo: uma loja pode decidir que precisa recuperar pedidos e pagamentos com perda máxima de poucos minutos, enquanto arquivos internos toleram uma janela maior. A decisão deve vir do impacto de perder ou interromper cada processo, e não de uma configuração padrão escolhida sem análise. Registre as metas e valide-as em testes.
Faça um teste de restauração que prove o caminho
Não espere um incidente para descobrir que a cópia não abre. Programe testes recorrentes, com escopo proporcional à criticidade, e registre duração, falhas e responsáveis. A CISA orienta testar restaurações completas e parciais; o NIST também publica recomendações voltadas à condução, manutenção e teste de arquivos de backup.
- Escolha um conjunto representativo: por exemplo, um banco de dados, arquivos de negócio e a configuração necessária para colocar o serviço no ar.
- Restaure em ambiente isolado, sem sobrescrever a produção; valide integridade e acesso com a equipe responsável.
- Meça o tempo desde a autorização até o serviço estar utilizável, incluindo etapas manuais e dependências externas.
- Compare o resultado às metas de RPO e RTO. Anote o que faltou — chaves, senhas guardadas com segurança, documentação, licenças ou ordem de inicialização.
- Atualize o procedimento e repita o teste após mudanças importantes na aplicação, banco, infraestrutura ou política de retenção.
Uma restauração de amostra é um começo, não prova que todo o ambiente será recuperado. Para sistemas críticos, teste também a sequência de recuperação e as dependências necessárias à operação.
Prepare a resposta antes da urgência
Mantenha uma lista priorizada de sistemas, contatos e passos para interromper acessos suspeitos e iniciar a recuperação. Guarde uma cópia do procedimento fora do ambiente que pode ficar indisponível. Em caso de suspeita de ransomware, não restaure às pressas sobre sistemas possivelmente comprometidos: contenção e análise devem preceder a retomada, para reduzir o risco de reinfecção.
Uma operação em VPS ou cloud server também precisa considerar cópias de configurações e dados persistentes, além dos arquivos da aplicação. A imagem de uma máquina pode acelerar reconstruções, mas não substitui backups consistentes de bancos e arquivos nem a validação do serviço recuperado.
Checklist para revisar sua estratégia
- Os dados críticos e seus responsáveis estão identificados?
- Há uma cópia que não dependa das credenciais e do acesso cotidianos da produção?
- As retenções cobrem o período em que um problema pode passar despercebido?
- O teste mais recente incluiu uma restauração real e teve resultado documentado?
- As metas de perda de dados e tempo parado foram acordadas com as áreas de negócio?
- O procedimento e os acessos necessários continuam disponíveis se a rede principal estiver comprometida?
Como a HAD Cloud pode ajudar
Se sua empresa está avaliando hospedagem, VPS ou infraestrutura em nuvem, inclua backup e recuperação na conversa desde o início: quais dados precisam de cópia, quem administra os acessos e como será testada a restauração. Converse com a HAD Cloud sobre a infraestrutura adequada ao seu projeto e confirme, antes da contratação, quais recursos de backup e responsabilidades estão incluídos na solução escolhida.
Perguntas frequentes
Backup na nuvem é suficiente contra ransomware?
Não necessariamente. Se o backup estiver acessível com as mesmas credenciais ou sincronizar alterações maliciosas, pode ser afetado. Segregação de acesso, cópias offline ou protegidas e testes ajudam a reduzir esse risco; a arquitetura depende do ambiente.
Com que frequência devo testar a restauração?
Defina uma cadência baseada na criticidade e no ritmo das mudanças, e repita o teste após alterações relevantes. O importante é registrar evidências de uma restauração funcional e corrigir os problemas encontrados, não apenas confirmar que o job de backup terminou.
Qual é a diferença entre RPO e RTO?
RPO limita a quantidade de dados que se aceita perder, expressa como tempo desde a última cópia recuperável. RTO limita o tempo para restabelecer o serviço. Ambos precisam ser realistas e validados em exercícios.
Fontes consultadas
- CISA — #StopRansomware Guide (orientações sobre cópias offline e criptografadas, testes e preparação para recuperação).
- NIST — Protecting Data from Ransomware and Other Data Loss Events (guia para conduzir, manter e testar arquivos de backup).
- NIST SP 800-34 Rev. 1 — Contingency Planning Guide (planejamento de contingência para sistemas de informação).
