Ter uma cópia dos arquivos e do banco de dados é essencial, mas não encerra o plano de continuidade. Depois de uma falha ou de um ataque, um site pode continuar indisponível mesmo com os dados recuperados: talvez o DNS ainda aponte para o destino antigo, as credenciais não estejam acessíveis, o certificado TLS precise ser reinstalado ou a aplicação dependa de serviços que ainda não foram reativados.
A orientação atual do NIST IR 8374 Rev. 1, publicado em junho de 2026, trata o risco de ransomware ao longo de governança, identificação, proteção, detecção, resposta e recuperação. Na prática, isso significa planejar não apenas a cópia dos dados, mas também como retomar os serviços. A CISA recomenda manter backups críticos criptografados e offline e testar regularmente sua disponibilidade e integridade em um cenário de recuperação.
O que pode impedir a volta do site?
Considere uma loja virtual com arquivos e banco restaurados. Ainda podem faltar o endereço IP de destino, a configuração de DNS, o certificado, variáveis de ambiente, chaves de integração, tarefas agendadas, regras de firewall ou a ordem correta para iniciar banco e aplicação. Uma restauração de dados não reconstitui automaticamente todos esses componentes.
Faça um inventário simples das dependências: domínio e DNS; servidor e sistema operacional; aplicação e versões; banco de dados; arquivos enviados; certificados; integrações externas; contas administrativas; e procedimentos de contato. Registre onde cada informação é mantida e quem pode acessá-la durante uma indisponibilidade.
Monte um runbook de recuperação executável
Um runbook é uma sequência de instruções operacionais. Mantenha-o fora do ambiente principal — por exemplo, em cópia offline protegida — para que permaneça acessível se as contas ou sistemas da empresa forem comprometidos.
- Defina prioridades: qual serviço precisa voltar primeiro e quais sistemas dependem dele?
- Preserve evidências e contenha o incidente: não reconecte sistemas potencialmente comprometidos sem avaliação; envolva a equipe técnica responsável.
- Prepare um ambiente limpo: valide sistema operacional, versões e configurações antes de restaurar dados.
- Recupere na ordem documentada: infraestrutura, banco, arquivos e aplicação; depois teste integrações, DNS e certificado.
- Valide com critérios observáveis: autenticação, busca, checkout ou formulários, gravação no banco, envio de e-mail e logs.
- Registre tempos e falhas: o exercício deve revelar etapas que precisam de melhoria, não apenas confirmar que um arquivo existe.
Teste sem colocar a produção em risco
Restaure uma cópia em ambiente isolado, com acesso restrito e sem enviar mensagens reais a clientes. Confira se os dados são legíveis, se a aplicação inicia e se as dependências documentadas estão disponíveis. Um teste parcial — por exemplo, abrir alguns arquivos — ajuda, mas não substitui um ensaio do fluxo de recuperação de ponta a ponta.
Defina também metas de RPO (quanto de alteração recente a empresa aceita perder) e RTO (quanto tempo aceita ficar sem o serviço). Elas devem refletir a operação e ser verificadas em exercícios; não são garantias produzidas apenas por contratar armazenamento ou fazer cópias com maior frequência.
Checklist rápido
- O backup inclui banco, arquivos e configurações necessários?
- Há uma cópia isolada das credenciais e instruções de recuperação?
- O domínio, DNS, certificado e integrações aparecem no inventário?
- Alguém além de uma pessoa-chave consegue executar o procedimento?
- O teste mede tempo de recuperação e valida funções reais do site?
- As lições do exercício geraram responsáveis e prazos de correção?
FAQ
Se o backup está íntegro, por que o site pode não voltar?
Porque arquivos e banco podem ser apenas parte do serviço. DNS, certificados, configuração, acessos, integrações e a ordem de inicialização também podem ser necessários.
Com que frequência devo testar a restauração?
Não existe uma frequência universal: defina-a conforme impacto, mudanças no ambiente e metas de recuperação. Teste após alterações relevantes e estabeleça uma cadência que a equipe consiga cumprir.
Backup em nuvem substitui uma cópia offline?
Não necessariamente. Avalie isolamento, permissões, retenção, possibilidade de exclusão por uma conta comprometida e procedimento de recuperação. A CISA recomenda backups críticos offline e criptografados; a arquitetura adequada depende do risco e dos requisitos aplicáveis.
Continuidade começa antes da falha
Documentar dependências e ensaiar a restauração transforma um backup em um processo de recuperação mais confiável. Para empresas que operam sites ou aplicações em servidores próprios ou em cloud, vale revisar tanto a proteção dos dados quanto a infraestrutura necessária para reconstruir o serviço. Converse com a equipe da HAD Cloud sobre suas necessidades de hospedagem ou infraestrutura, sem presumir que um serviço específico substitua seu plano de backup e continuidade.
