APRENDER. PRATICAR. EVOLUIR.O resultado a recuperar
Começa pela função de negócio e pelo critério de recuperação acordado. Se o fecho depende de aplicação, chaves, parceiro e validação de dados, arrancar uma VM não demonstra recuperação desse processo. Um teste parcial pode ser útil desde que o seu âmbito fique explícito. Na prática desta aula existem cinco registos sintéticos, R1 a R5. Todos apresentam um tempo inferior ao RTO de 45 minutos, mas só R1 cumpre simultaneamente os critérios registados. A diferença ensina a auditar a conclusão, não apenas a aceitar a cor do relatório de execução.
Tempo e perda de dados são dimensões distintas
R3 regista 44 minutos de recuperação e uma lacuna de dados de sete minutos, perante RTO de 45 e RPO de cinco. O tempo cumpre o objetivo indicado, mas a lacuna excede o limite. Não subtraias a margem de um minuto do RTO ao RPO: são medidas com origens e significados diferentes. Em auditoria real, verifica como foram definidos o início, o fim e o ponto dos dados, incluindo aceitação e reconciliação. Um valor de duração calculado até ao arranque técnico pode ser incompatível com um RTO definido até à aceitação de negócio.
Dados desconhecidos não são sucessos
R5 não tem valor de lacuna de dados. Em SQL, a comparação com NULL não produz uma confirmação positiva de cumprimento. A condição NOT(data_gap > rpo) também não significa «todos os casos sem falha conhecida»: o resultado desconhecido não é selecionado pelo WHERE. Mantém uma consulta explícita para campos nulos e apresenta estado desconhecido separado de cumprimento e falha. Substituir NULL por zero inventa ausência de perda. COUNT(data_gap) devolve quatro valores conhecidos, enquanto a tabela contém cinco exercícios. O denominador deve responder à pergunta de auditoria, não ser escolhido pelo comportamento conveniente de uma função.
Dependências e evidência de aceitação
R2 tem 20 minutos, mas a chave necessária está indisponível e não há aceitação. R4 tem 35 minutos, porém a ligação ao parceiro e a aceitação não foram validadas. Estes registos não demonstram recuperação integral, apesar do bom tempo. Investiga se o ensaio excluiu dependências por desenho, se houve falha ou se faltou recolher evidência. Cada situação conduz a uma conclusão diferente. Um relatório honesto pode afirmar «arranque técnico demonstrado; processo completo não testado». Não exige criar impacto em produção para todo o teste; exige adequação do método ao que se pretende concluir.
Exercício e plano de acompanhamento
Compara a consulta que seleciona apenas elapsed <= rto com a consulta completa apresentada abaixo. A primeira devolve R1 a R5; a segunda devolve R1. Prepara um pedido diferente para R2, R3, R4 e R5: capacidade de usar a chave, tratamento da lacuna superior ao RPO, validação da dependência externa e determinação do ponto dos dados. Define quem responde e que evidência permite fechar cada item. Um novo ticket ou uma data prometida não prova correção. O acompanhamento termina com evidência proporcional à observação, preservando limites quando o teste continua parcial.
SELECT id FROM recovery WHERE elapsed<=rto ORDER BY id;
SELECT id FROM recovery
WHERE elapsed<=rto AND data_gap<=rpo
AND key_available=1 AND partner_validated=1 AND business_accepted=1
ORDER BY id;
SELECT id FROM recovery WHERE data_gap IS NULL;
SELECT COUNT(*),COUNT(data_gap) FROM recovery;Cinco ensaios cumprem a condição temporal isolada; apenas um cumpre todas as condições registadas. O auditor comunica os quatro limites sem os confundir.
Armadilhas comuns
RTO como RPO; NULL como zero; tempo de arranque como recuperação aceite; exclusão de parceiros como teste integral; ticket aberto como correção concluída.
Tópicos relacionados: RTO e RPO · Dependências e aceitação
Recuperabilidade exige uma conclusão por critério e por âmbito. Um indicador agregado não deve esconder dependências nem dados desconhecidos.
Referência: Assessing Security and Privacy Controls in Information Systems and Organizations · CISA outline effective August 1, 2024