Guia de contingência para dados críticos.
Uma falha de banco de dados raramente começa como uma catástrofe. Pode ser uma alteração de schema sem plano de reversão, uma réplica atrasada, uma credencial exposta ou um backup que nunca foi restaurado. Quando a operação descobre o problema, pedidos deixam de ser processados, pagamentos falham e a confiança do cliente entra em risco. Um guia de contingência para dados existe para evitar que uma decisão tomada sob pressão defina o futuro da operação.
Para ambientes críticos, contingência não é um arquivo esquecido em uma pasta de compliance. É um conjunto operacional de decisões técnicas, responsáveis, limites de negócio e procedimentos testados. O objetivo não é prometer ausência de falhas. É limitar a perda de dados, recuperar o serviço com controle e preservar evidências para corrigir a causa raiz.
O que um guia de contingência para dados precisa resolver
Um plano útil responde, antes do incidente, a quatro perguntas diretas: quais dados são críticos, quanto dado a empresa pode perder, em quanto tempo o serviço precisa voltar e quem tem autoridade para executar cada ação. Sem essas respostas, uma equipe pode restaurar uma base antiga enquanto outra tenta promover uma réplica inconsistente. O incidente técnico vira um incidente de governança.
O ponto de partida são RPO e RTO. O RPO, ou objetivo de ponto de recuperação, define a perda máxima aceitável de dados. Um RPO de 15 minutos admite a perda das alterações realizadas nos 15 minutos anteriores à falha. O RTO, ou objetivo de tempo de recuperação, determina em quanto tempo o serviço deve ser restabelecido.
Essas metas não podem ser escolhidas por conveniência técnica. Uma operação de pagamentos pode exigir RPO próximo de zero para o livro transacional, enquanto um repositório de relatórios internos pode aceitar horas de defasagem. Tratar ambos da mesma forma aumenta custo sem elevar proteção onde ela realmente importa. A contingência precisa refletir impacto financeiro, obrigação regulatória, dependências entre sistemas e tolerância operacional.
Comece pelo inventário e pela classificação dos dados
Não existe recuperação confiável para um ambiente que ninguém conhece por completo. O guia deve registrar bancos, versões, mecanismos de replicação, volumes, conexões de aplicativos, contas de serviço, chaves de criptografia, jobs agendados e dependências externas. Também deve indicar onde cada ativo está hospedado e quais acessos são necessários durante uma crise.
Classifique as bases por criticidade. Dados de pedidos, saldos, autenticação, faturamento e cadastro sensível merecem prioridade distinta de dados temporários, caches ou ambientes de homologação. Essa separação determina frequência de backup, retenção, arquitetura de réplica e ordem de recuperação.
A classificação deve considerar a LGPD. Dados pessoais e dados sensíveis exigem controles de acesso, criptografia, trilhas de auditoria e descarte compatível com a política de retenção. Copiar uma base de produção para um ambiente emergencial sem mascaramento, sem registro ou sem controle de privilégio pode criar uma segunda crise: a de segurança e conformidade.
Defina cenários reais, não uma falha genérica
Um plano que diz apenas “restaurar o backup” não é um plano. A resposta muda conforme o tipo de incidente. Corrupção lógica, exclusão acidental, indisponibilidade regional, ransomware, falha de storage, degradação severa de performance e perda de credenciais exigem caminhos diferentes.
Na exclusão acidental, por exemplo, o recurso decisivo pode ser a recuperação point-in-time, capaz de restaurar o banco até instantes antes do comando destrutivo. Em uma indisponibilidade completa da região de cloud, a prioridade tende a ser promover uma réplica em outra zona ou região, validar a consistência e redirecionar o tráfego do aplicativo. Em ransomware, restaurar rapidamente sem investigar a origem pode recolocar o invasor dentro do ambiente recuperado.
Documente para cada cenário o gatilho de acionamento, os sinais técnicos esperados, o responsável pela decisão, o procedimento de contenção e o critério de retorno à normalidade. Inclua também o que não deve ser feito. Durante uma corrupção, por exemplo, gravar dados em uma réplica suspeita ou reiniciar serviços repetidamente pode eliminar evidências e ampliar o dano.
Arquitetura de recuperação: backup não basta
Backup é a última linha de defesa, não a única. Uma estratégia madura combina cópias consistentes, logs de transação, replicação, isolamento, monitoramento e procedimentos de restore validados. O desenho correto depende do mecanismo de banco, do volume de escrita, do RPO contratado e do orçamento disponível.
A regra 3-2-1 continua relevante: manter ao menos três cópias dos dados, em dois tipos de mídia ou domínios de falha, com uma cópia fora do ambiente primário. Para operações críticas, a cópia externa deve ser protegida contra alteração e exclusão indevidas. Imutabilidade e segregação de credenciais reduzem o risco de um ataque comprometer simultaneamente produção e backup.
Réplicas de leitura ou de alta disponibilidade ajudam a reduzir o RTO, mas não substituem backup. Se uma exclusão lógica, um erro de aplicativo ou uma corrupção for replicada, todas as réplicas podem reproduzir o problema. Da mesma forma, um backup diário pode atender uma base analítica, mas será insuficiente para uma plataforma transacional com RPO de poucos minutos. Nesse caso, logs contínuos e recuperação pontual passam a ser obrigatórios.
O plano também precisa proteger os componentes de controle: configurações de cluster, parâmetros de banco, manifests de infraestrutura, regras de rede, segredos e chaves de criptografia. Recuperar os arquivos de dados sem restaurar a capacidade de acesso e operação não devolve o serviço ao negócio.
Teste a recuperação sob condições controladas
O erro mais caro é confundir sucesso de backup com sucesso de recuperação. Um job pode terminar sem erro e ainda gerar um arquivo incompleto, criptografado com uma chave indisponível ou incapaz de ser restaurado dentro do RTO. A única evidência aceitável é um restore executado, validado e registrado.
Estabeleça testes periódicos com objetivos claros. Restaure uma amostra representativa, valide integridade, compare contagens e checksums quando aplicável, confirme permissões e suba o aplicativo em um ambiente isolado. Meça o tempo real desde o acionamento até a disponibilidade. Se o processo leva seis horas e o RTO aprovado é de duas, o plano falhou mesmo que os dados tenham sido recuperados.
Simulações mais completas devem incluir failover, indisponibilidade de fornecedor, perda de acesso administrativo e cenários de corrupção lógica. Não é necessário testar todos os eventos com a mesma frequência, mas é necessário testar os mais prováveis e os mais impactantes. Cada exercício deve gerar evidências, ajustes no runbook e responsáveis com prazo definido.
Organize a resposta a incidentes
Em uma crise, especialistas técnicos não podem gastar os primeiros 30 minutos procurando telefone, senha ou aprovação. O guia deve definir uma cadeia de acionamento 24/7, com contatos atualizados, níveis de escalonamento e canais de comunicação independentes do ambiente afetado.
A operação precisa ter um comandante do incidente, mesmo que essa função seja temporária. Essa pessoa coordena prioridades, aprova mudanças de alto impacto e mantém executivos e áreas de negócio informados. DBAs e engenheiros executam ações técnicas; segurança avalia comprometimento; produto e atendimento comunicam impactos conforme o caso. Separar decisão, execução e comunicação reduz ruído e evita intervenções concorrentes.
Registre horários, comandos relevantes, decisões, métricas e mudanças realizadas. Essa trilha é essencial para auditoria, análise forense e revisão posterior. Também evita que a empresa repita, no próximo incidente, os mesmos diagnósticos e tentativas que já se mostraram ineficazes.
Métricas que mostram se a contingência funciona
Um guia de contingência para dados deve ser acompanhado como um processo operacional, não revisado apenas após uma falha. Meça taxa de sucesso dos backups, idade da última cópia válida, tempo de restauração, atraso de replicação, aderência a RPO e RTO, resultados de testes e quantidade de acessos privilegiados fora do padrão.
Alertas precisam chegar antes da indisponibilidade. Backup que falhou, storage perto do limite, réplica com lag crescente e aumento anormal de erros de I/O são sinais de risco que exigem ação preventiva. Monitoramento 24/7 sem time capaz de interpretar e atuar sobre o alerta cria apenas uma coleção de notificações.
A HTI Tecnologia trabalha essa disciplina na camada em que o negócio mais sofre durante um incidente: o banco de dados. Senioridade técnica, monitoramento contínuo e runbooks atualizados transformam recuperação de emergência em uma operação controlada, com decisões baseadas em evidência e impacto.
A contingência precisa acompanhar a mudança
Uma base que era simples há seis meses pode ter ganhado novos microsserviços, integrações, regiões de cloud, regras de retenção e cargas transacionais. Se o plano não acompanha essas alterações, ele descreve uma infraestrutura que já não existe. Revise-o após mudanças arquiteturais, incidentes relevantes, auditorias e entrada de novos dados críticos.
O melhor momento para descobrir que uma recuperação não cabe no RTO não é durante uma madrugada de indisponibilidade. É em um teste planejado, com dados medidos, responsáveis presentes e espaço para corrigir a arquitetura antes que o negócio dependa dela.