O pipeline está funcionando novamente. Você pode confiar nos dados?

Após uma falha ou interrupção na replicação, uma reinicialização bem-sucedida prova apenas uma coisa: a replicação está funcionando novamente. Não prova que todas as alterações foram recebidas. Não prova que as exclusões foram processadas. Não prova que os valores estão atualizados. E não prova que as equipes subsequentes devem confiar nos dados.

É por isso que a validação pós-recuperação é importante.

As diretrizes de integridade de dados do NIST abordam a recuperação como algo que vai além da simples restauração da disponibilidade. Elas enfatizam a detecção e a resposta oportunas à perda de integridade, bem como o papel da preparação, do registro de logs e das ferramentas apropriadas para minimizar o tempo de inatividade e as perdas quando os dados podem ter sido corrompidos ou alterados.

Antes de declarar a recuperação completa, as equipes precisam de evidências suficientes para responder a uma pergunta simples: em que nos baseamos quando dizemos às pessoas que os dados podem ser usados ​​com segurança novamente?

Resposta rápida: Como validar os dados após a recuperação do CDC?

A validação precisa responder a duas perguntas diferentes, mas igualmente importantes.

• A replicação foi recuperada com sucesso?
  Esta é a questão operacional. O processo foi reiniciado. O atraso retornou aos níveis esperados. O acúmulo de tarefas foi zerado.
• Os dados recuperados são confiáveis?
  Esta é a questão da integridade dos dados. O alvo reflete as mudanças esperadas. Registros importantes estão presentes. Exclusões foram processadas. Não restam discrepâncias inexplicáveis.

Um processo bem-sucedido ajuda a comprovar que a recuperação ocorreu. A validação ajuda a comprovar que a recuperação produziu dados confiáveis. Um processo prático de validação pós-recuperação possui cinco partes:

• Defina a janela de recuperação.
• Identifique os dados e os sistemas subsequentes que foram expostos.
• Utilize as evidências disponíveis da fonte, da plataforma de replicação e do alvo.
• Verifique especificamente os modos de falha que são relevantes.
• Documente o que foi validado, o que foi constatado e o que permanece incerto.

Não confie em apenas um sinal.

Um processo em execução indica que a replicação está funcionando. A contagem de linhas fornece informações sobre o conjunto de dados resultante. Uma comparação entre a origem e o destino identifica diferenças dentro do escopo suportado. Os logs e diagnósticos da plataforma informam o que aconteceu operacionalmente. As verificações em nível de negócios indicam se o resultado final faz sentido.

Em conjunto, esses sinais podem sustentar uma conclusão defensável. Vamos analisá-los.

A validação é um processo de cinco etapas.

As seções a seguir detalham essas cinco áreas. Algumas etapas exigem múltiplas verificações. Por exemplo, a comparação entre dados de origem e de destino pode envolver a validação de contagens, a identificação de alterações ausentes, a verificação de duplicatas, a confirmação de exclusões e a investigação de valores obsoletos.

O objetivo não é concluir treze tarefas desconexas. É reunir evidências suficientes para responder a uma única pergunta: podemos confiar nos dados recuperados?

Defina a janela de recuperação.

Antes de comparar qualquer coisa, estabeleça qual período você está tentando comprovar. Comece com o último ponto antes do incidente em que a replicação estava funcionando conforme o esperado. Em seguida, identifique quando a recuperação e o acompanhamento atingiram o ponto que você está avaliando.

Isso lhe dá uma janela de recuperação: do último estado confiável conhecido → passando pela interrupção → passando pela recuperação → até o estado em que você agora deseja confiar. Dependendo da fonte e da plataforma, referências úteis podem incluir:

• carimbos de data/hora
• reiniciar ou estado do processo
• pontos de controle
• favoritos
• posições de registro de origem
• coordenadas de recuperação específicas da plataforma

Para ambientes Db2 para z/OS, as equipes também podem trabalhar com conceitos específicos da fonte, como RBA ou LRSN, quando apropriado. A terminologia exata varia. O importante é que todos que avaliam a recuperação estejam falando sobre o mesmo período e o mesmo limite lógico.

Como as posições do log de origem, incluindo Db2 para z/OS RBA/LRSN, podem ajudar a ancorar a validação pós-recuperação

As posições do log de origem podem ajudar as equipes a identificar o período de processamento que estão tentando avaliar. Em ambientes Db2 para z/OS, o RBA ou o LRSN podem ser relevantes para entender a posição do log de origem, dependendo da configuração e do ambiente.

Essas coordenadas podem ajudar a direcionar a investigação. Elas não devem ser consideradas como prova definitiva de que o alvo foi concluído. A equipe ainda precisa conectar o estado de origem relevante, as evidências da plataforma de replicação e o estado de destino resultante.

Perguntar:

Quando o problema começou, de fato?

Qual foi o último estado em que confiamos?

Quando começou a recuperação?

Quando o alvo retornou ao estado que estamos avaliando agora?

Que transações, conjuntos de dados, tabelas, arquivos ou processos subsequentes se enquadram nesse intervalo?

Por que isso importa

Se a janela de validação for vaga, a conclusão também será vaga, portanto, você não poderá responder com segurança à pergunta: "Perdemos alguma coisa?" até que haja consenso sobre: ​​"Entre quais dois pontos?"

Identifique o que foi de fato exposto.

Não valide tudo automaticamente com o mesmo nível de esforço. Primeiro, entenda o que mudou durante o período de recuperação e quais sistemas subsequentes dependiam desses dados.

Perguntar:

• Quais fontes e alvos foram afetados?
• Quais tabelas, arquivos, conjuntos de dados ou domínios de dados foram alterados durante o período analisado?
• Quais aplicações, relatórios, análises, APIs ou processos operacionais subsequentes dependem deles?
• Foram utilizados dados de destino desatualizados enquanto a replicação estava atrasada?
• Quais dados são suficientemente críticos para o negócio a ponto de exigirem uma validação mais aprofundada?
• Existem usos de alto impacto relacionados a clientes, relatórios, finanças, operações, regulamentação ou outros?

Isso ajuda a determinar a profundidade da validação necessária. Uma breve interrupção que afete dados de baixo risco pode justificar uma abordagem de validação diferente de uma longa interrupção envolvendo liquidação, reclamações, relatórios regulatórios ou outro processo crítico.

A questão prática: “O que realmente importa nessa lacuna?”

Esse é um ponto de partida mais útil do que aplicar a mesma lista de verificação cegamente a todas as tabelas.

Faça um inventário das provas que você realmente possui.

A validação pós-recuperação deve basear-se em três fontes:

A. A fonte

O que a fonte confiável informa sobre o período afetado? As evidências relevantes podem incluir:

• Registros de origem
• Histórico de transações/alterações
• Carimbos de data/hora
• Chaves
• Informações de registro ou sequência específicas da fonte
• Totais de negócios
• Outras evidências do sistema de origem

B. A plataforma de replicação

O que a plataforma pode mostrar sobre o ocorrido? Dependendo do produto e da configuração, isso pode incluir:

• Estado de reinicialização/processo salvo
• Informações sobre o estado e monitoramento
• Erros e diagnósticos
• Informações de atraso ou de recuperação
• Capacidades de comparação ou validação suportadas
• Outras evidências operacionais específicas da plataforma

C. O alvo

O que o alvo contém exatamente agora? Dependendo dos dados e do caso de uso, talvez seja necessário inspecionar:

• Registros
• Chaves de negócios
• Contagens
• Valores
• Carimbos de data/hora
• Exceções de destino
• Resultados a jusante
• Comportamento em nível de aplicação

A validação mais robusta geralmente vem da conexão de evidências entre essas camadas, e não de se tomar o status de "sucesso" de um sistema como a resposta final.

Comece com uma visão ampla, mas não pare na contagem de linhas.

A contagem de linhas é útil. No entanto, é também um dos primeiros indicadores que profissionais experientes alertam para não a considerarem suficiente. Dois conjuntos de dados podem ter o mesmo número de linhas e ainda assim estarem incorretos.
Você poderia ter:

• uma linha em falta e uma linha inesperada
• a chave correta com um valor incorreto
• um registro que deveria ter sido excluído, mas ainda existe
• uma atualização posterior sem um estado esperado anterior
• diferenças que se anulam mutuamente na contagem total

Portanto, use verificações amplas para identificar onde investigar mais a fundo. Verificações amplas úteis podem incluir:

• contagem esperada de linhas ou registros
• volumes de mudança esperados
• intervalos principais
• totais de negócios de alto nível
• carimbos de data/hora
• exceções inesperadas
• status relatado pela plataforma

Uma discrepância indica imediatamente que algo precisa ser investigado. Uma correspondência indica que essa verificação específica foi aprovada. Isso não significa que tudo esteja comprovado como correto.

A contagem de linhas é um sinal, não uma garantia de que tudo está funcionando perfeitamente.

Compare a origem e o destino onde for relevante.

Após definir a janela de recuperação e o escopo afetado, compare a origem e o destino em um ponto logicamente apropriado. Dependendo do seu ambiente, a validação pode usar:

• Chaves de negócios
• Comparação em nível de recorde
• Colunas selecionadas
• Hashes ou somas de verificação, quando apropriado.
• Totais de controle
• Carimbos de data/hora
• Valores de origem e destino
• Recursos de comparação suportados pela plataforma

O objetivo não é necessariamente comparar cada byte de cada conjunto de dados. É identificar se os dados que deveriam ser representados no destino estão representados corretamente o suficiente para sustentar a conclusão necessária.

Tenha cuidado com o momento certo.

A origem e o destino precisam ser comparados em estados significativos e logicamente compatíveis. Se a origem continuar mudando enquanto o destino ainda está se ajustando, uma diferença não significa automaticamente que a recuperação falhou. Pode simplesmente significar que os dois lados estão sendo medidos em momentos diferentes.

É por isso que a janela de recuperação e o limite de comparação são importantes.

Como validar a integridade da replicação CDC do mainframe para a nuvem após a recuperação: checksums, posições de log e reconciliação

Não existe uma fórmula universal para validação. No entanto, as equipes geralmente combinam diversas formas de evidência ao validar dados após a recuperação de um CDC em um mainframe.

Contagens e totais de controle: Úteis para identificar diferenças óbvias nos volumes esperados ou nos agregados de negócios.

• Ideal para: detecção ampla de anomalias.
• Não comprova: que os registros ou valores individuais corretos estejam presentes.

Chaves e comparações em nível de registro: Úteis para identificar registros ausentes, inesperados ou incompatíveis dentro de um escopo definido.

• Bom para: encontrar diferenças específicas.
• Não comprova automaticamente: a sequência de transações ou qualquer forma de exatidão histórica.

Hashes ou somas de verificação: Quando apropriado, hashes ou somas de verificação podem ajudar a comparar conjuntos de valores de forma eficiente.

• Bom para: detectar se os valores de origem e destino são diferentes.
• Isso não indica automaticamente por que eles diferem ou se o comportamento específico da sequência estava correto.

Carimbos de data/hora, estado de reinicialização e posições do log de origem: esses dados podem ajudar a estabelecer o período ou o estado de processamento que está sendo avaliado. Para fontes de mainframe, a terminologia específica da posição depende da plataforma subjacente.

• Bom para: dar sustentação à investigação de recuperação.
• Isso não prova automaticamente que os dados finais de destino estejam corretos.

Recursos de diagnóstico e comparação da plataforma: Sua plataforma de replicação pode fornecer evidências operacionais ou funcionalidades de comparação entre origem e destino.

• Ideal para: adicionar evidências específicas da plataforma ao processo de validação.
• Importante: entenda exatamente o que o recurso abrange para sua origem e destino. Não presuma que uma capacidade de comparação de plataformas comprove todas as dimensões de correção.

Validação em nível de negócios: Para fluxos de trabalho críticos, verifique se registros comerciais importantes, totais, eventos ou resultados fazem sentido após a recuperação.

• Útil para: determinar se os dados são utilizáveis ​​no contexto relevante.
• Não substitui: validação técnica quando a comprovação técnica for exigida.

A abordagem mais defensável costuma ser a validação em camadas: várias verificações respondendo a diferentes perguntas, em vez de uma única verificação que pretenda responder a tudo.

Como detectar transações ou alterações ausentes após a recuperação do CDC

A pergunta que os usuários fazem é simples: "Como sabemos que nada passou despercebido?"

Comece pela janela de recuperação. Em seguida, compare o que deveria ter atingido o alvo com o que de fato atingiu. Dependendo do ambiente, isso pode significar examinar:

• Registros de origem afetados
• Chaves de negócios de alto valor
• Alterar a atividade durante o intervalo
• Registros alvo
• Diagnóstico da plataforma
• Resultados de comparação entre origem e destino suportados
• Resultados a jusante

Observe com atenção especialmente os dados que foram alterados enquanto a replicação estava interrompida ou em fase de atualização.

Sinais de alerta

• Os registros esperados estão ausentes.
• As atualizações esperadas não estão refletidas.
• Os totais a jusante já não coincidem.
• Exceções de plataforma ou de destino permanecem sem explicação.

Transações específicas de alto valor não podem ser contabilizadas.

Não extrapole as conclusões além das evidências. Se você validou um subconjunto definido de tabelas ou uma janela de recuperação específica, mencione isso. Uma declaração defensável seria: “Validamos os conjuntos de dados afetados e a janela de recuperação usando essas verificações e não encontramos discrepâncias inexplicáveis.”

Isso é mais forte do que fazer uma afirmação absoluta que as evidências não podem sustentar.

Como identificar alterações duplicadas ou reprocessadas após a reinicialização do pipeline

Uma reinicialização ou recuperação pode gerar preocupações sobre se o trabalho foi processado mais de uma vez. O comportamento exato de repetição e duplicação depende da plataforma de replicação, da origem, do destino e da configuração.

Não assuma uma garantia de entrega universal. Em vez disso, identifique onde a aplicação duplicada ou repetida seria visível em seu ambiente. Os indicadores potenciais incluem:

• Registros adicionais inesperados
• Chaves comerciais duplicadas
• erros de restrição de alvo
• Contagens inconsistentes
• eventos de negócios repetidos
• Erros ou diagnósticos da plataforma
• Anomalias ao nível da aplicação

Em conjuntos de dados sem restrições naturais de unicidade, a detecção de duplicatas pode ser mais difícil.

Por isso, as equipes devem entender quais chaves ou regras de negócio tornam a duplicação visível antes que o incidente ocorra.

Como detectar exclusões ausentes após a recuperação do CDC

As exclusões merecem uma verificação própria, pois são fáceis de passar despercebidas. Um destino pode conter todos os registros esperados e ainda assim estar incorreto, pois inclui registros que não deveriam mais existir. A linguagem utilizada na prática para descrever esse problema é bastante direta: "Registros que foram excluídos da origem ainda estão presentes no destino."

Quando ocorrerem exclusões durante a janela de recuperação, verifique se o estado de destino relevante as reflete adequadamente. Dependendo do modelo de dados, isso pode envolver:

• Verificação das chaves de negócio afetadas
• Comparando a presença da fonte e do alvo
• Analisando os resultados da comparação entre plataformas suportadas
• Validar o comportamento subsequente em que os registros excluídos são relevantes.

Não assuma que uma comparação de contagens bem-sucedida sempre revelará exclusões ausentes.

Como identificar valores desatualizados ou incorretos

Às vezes, o registro está presente em ambos os lados. O problema é que o destino possui a versão incorreta. Procure por:

• Valores que não correspondem à fonte no ponto de comparação pretendido.
• Atualizações da janela de recuperação que não são refletidas
• Resultados a jusante usando um valor anterior
• Diferenças que não podem ser explicadas pelo tempo normal ou pela transformação.

Isso é importante porque uma simples verificação de existência pode ser bem-sucedida mesmo que o alvo ainda esteja desatualizado.

A questão não é apenas: "O recorde está lá?", mas sim: "O recorde está no estado em que esperamos que esteja?".

Como identificar alterações fora de ordem após a recuperação do CDC

A ordem é mais importante em algumas cargas de trabalho do que em outras. Se o resultado do negócio depende da sequência, a comparação do estado final pode não responder a todas as perguntas. Nesses cenários, as equipes podem precisar de evidências adicionais apropriadas para:

• A fonte
• O alvo
• A arquitetura de replicação
• O padrão de transação afetado
• O requisito específico de encomenda

Não assuma que um checksum ou a correspondência do estado da última linha comprovem a ordem histórica. Da mesma forma, não assuma que toda carga de trabalho exija validação sequencial transação por transação.

O padrão correto é: Validar o comportamento de ordenação que realmente importa para o processo de negócio e a arquitetura afetados.

Investigue as discrepâncias — não as elimine pela média.

Se uma verificação de validação encontrar uma diferença, considere-a como evidência para investigação.

Perguntar:

• Essa diferença de tempo é esperada?
• Há transformação envolvida?
• A comparação utilizou estados de origem e de destino equivalentes?
• Será que a meta ainda está sendo alcançada?
• Existe algum registro desaparecido sem explicação?
• Existe algo presente que deveria ter sido excluído?
• A alteração foi processada mais de uma vez?
• Um valor está desatualizado?
• Essa discrepância é um caso isolado ou faz parte de um padrão maior?

Em seguida, determine a remediação apropriada. Dependendo do ambiente, isso pode envolver:

• Corrigir um registro ou conjunto de dados identificado.
• Repetir uma etapa de validação
• Ressincronizando os dados afetados
• Realizar uma ressincronização mais ampla
• Manter o uso subsequente restrito até que o problema seja compreendido.

Não deixe que um grande número de verificações bem-sucedidas oculte uma discrepância inexplicável em dados críticos para o negócio.

Criar um registro de evidências pós-recuperação

A equipe que lidou com o incidente pode saber exatamente o que aconteceu hoje. Três meses depois, alguém pode perguntar: "Como sabíamos que os dados eram seguros para serem usados ​​novamente?"

Não os obrigue a reconstruir a resposta de memória. Crie um Registro de Evidências Pós-Recuperação conciso que inclua:

Período de Incidente: Quando a replicação foi afetada?

Ponto de recuperação: Em que ponto o processamento foi retomado, utilizando a terminologia apropriada à origem e à plataforma?

Escopo afetado: Quais fontes, destinos, conjuntos de dados, tabelas, arquivos ou processos subsequentes foram envolvidos?

Método de recuperação: Qual caminho de recuperação foi utilizado? Por exemplo:

• Reiniciar a partir do estado salvo
• Alcançar
• ressincronização direcionada
• Ressincronização ou recarga mais abrangente

Validação realizada: Quais verificações foram concluídas? Para cada verificação importante, registre:

• O que foi examinado?
• Qual período ou âmbito foi abordado?
• Qual era o objetivo da verificação?

Resultados: O que a equipe observou? Foram encontradas discrepâncias?

Remediação: O que foi corrigido, reprocessado ou resincronizado?

Exceções: O que permanece sem solução ou fora do escopo validado?

Conclusão: Que evidências sustentam a decisão de que os dados subsequentes relevantes estão prontos para uso?

Esse registro pode comprovar:

• Análise de incidentes
• Transferência de operações
• Comunicação a jusante
• Governança
• Auditoria
• Solução de problemas futuros
• Aprimoramento do manual de recuperação

Quem dá o sinal verde?

Essa é uma questão operacional que as equipes frequentemente deixam indefinida até que a pressão seja máxima. Alguém precisa decidir se os dados estão prontos para serem usados ​​novamente. Essa decisão pode envolver mais do que apenas a pessoa que reiniciou o pipeline. Dependendo do incidente, pode ser necessário o envolvimento de:

• A equipe de replicação ou engenharia de dados
• O proprietário do sistema de origem
• O proprietário da plataforma ou aplicação downstream
• operações de dados
• Um empresário
• Governança, risco ou outra função de controle

O processo de aprovação exato deve refletir a importância dos dados afetados.

Princípio fundamental: A equipe técnica deve ser capaz de explicar:

• O que foi afetado?
• O que foi validado
• O que as verificações estabeleceram
• O que permanece incerto
• Que exceções ainda existem?

Assim, os responsáveis ​​pelo uso posterior poderão tomar uma decisão informada.

Como informar às equipes subsequentes que os dados estão prontos novamente?

Evite os extremos. Não diga que está tudo bem se as suas evidências não sustentarem essa afirmação.

Mas também não despeje um relatório de incidentes técnicos sobre um stakeholder do negócio. Comunique quatro coisas com clareza:

• O que aconteceu: A replicação foi interrompida ou ficou atrasada durante um período definido.
• O que foi afetado: Identifique os dados ou sistemas subsequentes relevantes.
• O que foi validado: Explique o escopo das verificações realizadas.
• O que resta: Indique quaisquer exceções, limitações ou trabalhos de acompanhamento em aberto.

A mensagem mais útil seria algo como:

“A replicação foi concluída. Validamos os dados afetados durante o período do incidente usando as verificações descritas aqui. Não encontramos [diferenças inexplicáveis ​​/ estas diferenças identificadas, que foram corrigidas]. Esses conjuntos de dados subsequentes estão liberados para uso. Quaisquer exceções permanecem em aberto.”

A linguagem exata deve corresponder às evidências. É assim que se reconstrói a confiança sem fingir que a incerteza não existe.

Um oleoduto verde não é uma estratégia de validação.

O erro recorrente após uma recuperação é parar no status operacional: o processo está em execução, o atraso voltou ao normal e o painel está verde.

Todos querem encerrar a chamada da ponte. Mas nenhum desses sinais, por si só, comprova que os dados de destino afetados estejam corretos.

A questão crucial a ser respondida é: "Em que evidências nos baseamos quando dizemos às pessoas que elas podem confiar nesses dados novamente?"

Se a resposta não for clara, o incidente não está encerrado.

Como avaliar as capacidades de validação pós-recuperação

Nem todas as plataformas do CDC fornecem o mesmo nível de evidência após uma interrupção. Algumas funcionalidades são básicas. Outras podem reduzir significativamente o esforço, a incerteza e o risco envolvidos na comprovação do sucesso da recuperação.

Requisitos básicos

Todas as plataformas de CDC empresariais devem fornecer:

• Informações sobre reinicialização ou estado do processo
• Estado operacional e monitoramento
• Informações sobre erros e diagnósticos
• Visibilidade da atividade de recuperação
• Procedimentos básicos de recuperação para ambientes suportados

Essas funcionalidades ajudam as equipes a responder: A replicação foi recuperada e o processamento retomou?

A questão mais difícil é: podemos provar que os dados recuperados são confiáveis?

Funcionalidades importantes que nem sempre estão incluídas.

• Funcionalidade de comparação entre origem e destino
• Visibilidade da posição de recuperação e do histórico de processamento
• Apoio à recuperação histórica onde o histórico preservado está disponível
• Diagnósticos relevantes que apoiam a investigação da causa raiz.
• Evidências de inspeção e validação do estado de recuperação
• Visibilidade das discrepâncias descobertas durante a reconciliação.
• Suporte para validação eficiente de grandes conjuntos de dados
• Documentação e relatórios que dão suporte a requisitos de auditoria, governança ou aprovação subsequente.

Essas funcionalidades determinam o quanto de investigação manual é necessário antes que as equipes possam declarar com segurança a conclusão da recuperação. Nenhum recurso isolado deve ser considerado prova universal de que a recuperação foi bem-sucedida. A questão crucial é: “Que evidências esta plataforma fornecerá à nossa equipe após um evento de recuperação e de que validação adicional ainda precisaremos?”

Perguntas a fazer a todos os fornecedores do CDC

Peça ao fornecedor para demonstrar:

• Que estado de reinicialização ou processo é visível após uma interrupção?
• Que informações de monitoramento e diagnóstico os operadores podem inspecionar?
• Como a plataforma auxilia na recuperação após uma interrupção?
• Quais são as funcionalidades de comparação entre origem e destino disponíveis?
• Que diferenças essas capacidades de comparação conseguem, de fato, identificar?
• Quais são os limites dessas capacidades?
• Como essas capacidades se encaixam em um processo de validação mais amplo?
• Que provas as equipes podem reter para sustentar uma decisão de que tudo está bem?

O padrão deve ser o mesmo para todas as plataformas do CDC: Não aceite "o processo reiniciado" como prova. Pergunte o que os operadores podem inspecionar, comparar, testar e defender posteriormente.

Como o Rocket Data Replicate & Sync se encaixa nisso

O Rocket Data Replicate & Sync (RDRS) inclui funcionalidades que podem contribuir para a investigação e validação pós-recuperação de configurações suportadas.

As funcionalidades documentadas do RDRS incluem:

• Processo salvo e estado de reinicialização
• Informações de monitoramento e diagnóstico
• Funcionalidade de comparação em lote para fontes compatíveis.
• Suporte para processamento de logs arquivados em ambientes baseados em logs compatíveis, onde o histórico necessário permanece disponível.

Essas funcionalidades podem fornecer evidências operacionais e de validação durante uma investigação de recuperação. Como em qualquer plataforma de CDC (Centro de Controle e Prevenção de Doenças), as organizações devem avaliar o RDRS (Sistema de Resposta a Incidentes de Recuperação) em relação às suas fontes, alvos, configurações, requisitos de recuperação e procedimentos operacionais específicos. A questão mais importante é: "Que evidências o RDRS pode fornecer nos cenários de recuperação que nosso ambiente provavelmente enfrentará?"

Lista de verificação de validação pós-recuperação

Antes de informar aos usuários subsequentes que os dados estão prontos novamente, confirme:

• A janela de recuperação está claramente definida.
• As fontes, os alvos e os consumidores a jusante afetados são conhecidos.
• O atraso foi resolvido ou o estado restante foi compreendido.
• Foram analisadas as evidências relevantes referentes à fonte, à plataforma de replicação e ao alvo.
• A validação foi além do simples status do processo.
• Verificações amplas, como contagens ou totais, não eram consideradas provas universais.
• Registros importantes, valores ou indicadores-chave de negócios foram comparados quando apropriado.
• As alterações em falta foram consideradas.
• Alterações duplicadas ou repetidas foram consideradas quando relevantes.
• Foram consideradas as exclusões que ocorreram durante o período de recuperação.
• Valores desatualizados ou incorretos foram considerados.
• A ordenação foi avaliada nos casos em que a sequência era importante.
• Foram investigadas discrepâncias inexplicáveis.
• Qualquer correção ou ressincronização foi documentada.
• As demais exceções são explícitas.
• Os proprietários de imóveis a jusante entendem o que é seguro usar.
• As evidências que comprovam a inocência do paciente foram registradas.

Conclusão

Reativar o oleoduto é apenas metade da recuperação. A questão mais difícil é: "Como provar que os dados estão corretos?"

Comece definindo a janela de recuperação. Compreenda o que foi afetado. Utilize evidências da origem, da plataforma de replicação, do destino e do ambiente downstream. Procure atentamente por alterações ausentes, duplicatas, exclusões ausentes, valores obsoletos e problemas de ordenação onde forem relevantes. Investigue as discrepâncias em vez de presumir que são inofensivas. E deixe evidências suficientes para que alguém que não participou da chamada de incidente possa entender por que o destino foi liberado para uso.

Porque:

Voltar a funcionar não é o mesmo que estar recuperado.
E um oleoduto verde não significa que os dados sejam confiáveis.

A recuperação está completa quando o processo se estabiliza e a organização possui evidências suficientes para confiar novamente nos dados.

*NIST SP 1800-26: Integridade de Dados, Detecção e Resposta a Eventos Destrutivos

A seguir: Sua plataforma atual é boa o suficiente para recuperação de dados?

Se a recuperação depende repetidamente de validação manual, conhecimento tácito, investigação entre equipes ou incerteza sobre o que aconteceu durante o período de inatividade, a próxima questão pode ser maior do que o próprio incidente.

Como avaliar as capacidades de recuperação de dados de uma empresa quando a perda de dados é inaceitável

Utilize a estrutura de avaliação para definir o que sua plataforma deve tornar visível, testável e comprovável antes que a próxima falha ocorra.