Alta disponibilidade, backup e recuperação: modelo mental e decisões

Comece pela jornada, não pela nuvem

Imagine que um eletricista concluiu a ordem de serviço OS 742 depois de substituir um componente crítico. O aplicativo confirmou a operação, mas minutos depois o banco principal ficou indisponível. Há quatro perguntas diferentes escondidas nesse incidente:

1. O eletricista ainda consegue consultar e registrar trabalho?
2. A conclusão já confirmada continuará existindo?
3. Se o dado foi apagado ou corrompido, existe uma versão anterior recuperável?
4. Quem decide a ordem de restauração, executa o procedimento e confirma que o ERP convergiu?

Uma réplica pode responder à primeira pergunta, mas reproduzir a mesma exclusão que causou a terceira. Um arquivo de backup pode preservar os dados e, ainda assim, não restaurar porque a chave de criptografia expirou. Um provedor pode manter a infraestrutura funcionando enquanto a aplicação retorna erro porque depende de um ERP fora do ar. Portanto, confiabilidade não nasce de marcar a opção “multi-zone”; nasce de entender a jornada completa e provar como ela reage a falhas.

A publicação NIST SP 800-34 Rev. 1 organiza planejamento de contingência como uma disciplina de impacto, estratégias, planos, testes e manutenção. A documentação do PostgreSQL separa métodos de backup e alerta, implicitamente, que cada abordagem possui condições próprias de restauração. Essas fontes não escolhem o objetivo do seu negócio: quem opera a manutenção precisa declarar o que é tolerável.

Vocabulário que evita decisões erradas

Disponibilidade é a proporção ou condição em que uma jornada presta o serviço esperado. Ela não significa “nenhum componente falha”. Um sistema pode perder uma instância e continuar disponível por outra. Durabilidade é a expectativa de que um dado confirmado permaneça existente. É possível ter serviço disponível devolvendo dados antigos; também é possível ter dados duráveis em um serviço temporariamente inacessível.

Alta disponibilidade, frequentemente abreviada como HA (high availability), usa desenho e operação para reduzir interrupções dentro de uma meta. Redundância significa haver componentes capazes de assumir uma responsabilidade. Duas instâncias no mesmo host não protegem contra a queda desse host: compartilham o mesmo domínio de falha, isto é, a causa capaz de derrubá-las juntas. Um ponto único de falha é um componente cuja perda interrompe a jornada sem alternativa válida.

Failover é a troca para um componente saudável. Pode ser automático ou manual. Automação rápida não é necessariamente segura: durante uma partição de rede, dois primários podem aceitar escritas incompatíveis. Sistemas distribuídos às vezes usam quorum, um número mínimo de participantes que precisa concordar, para reduzir decisões concorrentes. Quorum não elimina indisponibilidade; ele troca parte da capacidade de continuar por consistência e proteção contra divergência.

Backup é uma cópia recuperável, retida e protegida de modo suficientemente independente da operação normal. Snapshot é uma fotografia de volume ou sistema em um instante; pode participar da política de backup, mas não é automaticamente independente, consistente ou imutável. Restore é a restauração técnica. Recuperação só termina quando dados, aplicação e jornada foram verificados.

Dois objetivos traduzem impacto em limites:

• RTO — Recovery Time Objective: tempo máximo planejado para restabelecer uma jornada.
• RPO — Recovery Point Objective: quantidade máxima de dados que pode ser perdida, expressa como distância temporal entre o desastre e o último ponto recuperável.

Se o RTO da consulta de manuais é quatro horas, uma operação manual temporária talvez baste. Se o RPO das intervenções críticas é zero, backups a cada 24 horas não atendem, mesmo que sejam restaurados em cinco minutos. DR — Disaster Recovery é recuperação de desastre: pessoas, prioridades, dependências, comunicação, infraestrutura, dados e validação coordenados. Um runbook torna o procedimento executável; um game day injeta uma falha controlada para provar o controle e treinar a equipe.

O mapa causal: continuar, voltar e reconstruir

O diagrama mostra três trilhas que se encontram na validação. Continuidade mantém ou degrada o serviço; backup recupera história; DR recompõe a operação. O erro clássico é desenhar somente componentes. Uma arquitetura com três servidores ainda falha se todos usam a mesma credencial comprometida, dependem do mesmo DNS ou gravam no mesmo banco sem cópia recuperável.

Limite do modelo

RTO e RPO são objetivos, não garantias automáticas. “RTO de uma hora” escrito numa planilha não prova que DNS, identidade, segredos, filas, banco e ERP voltarão em uma hora. A medição começa no momento definido pelo plano e termina quando a jornada acordada funciona, não quando uma máquina virtual liga. Da mesma forma, RPO observado é o ponto íntegro realmente recuperado, não a frequência nominal do job de backup.

Como derivar objetivos a partir do trabalho real

Comece com jornadas, não com bancos. Para cada uma, pergunte:

1. Quem depende dela e em qual turno?
2. Qual dano cresce com o tempo de indisponibilidade?
3. Que dado foi confirmado ao usuário?
4. É possível operar em papel, fila local ou modo somente leitura?
5. Quanto trabalho pode ser reconstruído com segurança?
6. Quais sistemas e pessoas precisam estar disponíveis para validar a volta?

Uma matriz inicial para manutenção pode ser:

Jornada	Modo degradado	RTO candidato	RPO candidato	Dependências essenciais
Consultar manual vigente	cópia local controlada	4 h	24 h	storage, identidade, catálogo
Abrir OS não crítica	fila offline com sincronização	2 h	15 min	API, banco, dispositivo
Registrar intervenção crítica	formulário contingencial numerado	30 min	próximo de zero	API, banco, auditoria, supervisor
Sincronizar conclusão com ERP	estado pending_erp	8 h	zero para evento local	outbox, worker, contrato ERP

Esses números são exemplos didáticos, não recomendação universal. O owner do negócio deve aceitar o impacto e financiar o controle correspondente. Reduzir RTO e RPO tende a aumentar custo, complexidade e disciplina operacional.

Um cálculo simples e executável

O código abaixo converte uma meta percentual em orçamento aproximado de indisponibilidade por janela. Ele não substitui um SLO completo, pois não define o que conta como sucesso nem exclui manutenção planejada; serve para tornar a ordem de grandeza visível.

export function downtimeBudgetMinutes(
  availabilityPercent: number,
  windowDays: number,
): number {
  if (availabilityPercent <= 0 || availabilityPercent > 100) {
    throw new RangeError("availabilityPercent deve estar em (0, 100]");
  }
  const windowMinutes = windowDays * 24 * 60;
  return windowMinutes * (1 - availabilityPercent / 100);
}

console.log(downtimeBudgetMinutes(99.9, 30).toFixed(1)); // 43.2

Esse resultado não diz que cada incidente pode durar 43 minutos: todos os incidentes da janela consomem o mesmo orçamento. Também não mede perda de dados; isso pertence ao RPO.

Escolha controles por cenário de falha

Falha de processo ou instância

Health checks, reinício e outra instância podem bastar. O teste deve derrubar a instância e medir a jornada, não apenas verificar se o orquestrador criou outro processo. Sessão guardada somente na memória local pode impedir failover transparente.

Falha de zona ou infraestrutura compartilhada

Distribua componentes por domínios realmente independentes e confirme que balanceador, banco, segredos e observabilidade não permanecem na zona perdida. A AWS Reliability Pillar é uma fonte oficial útil para princípios de recuperação automática, teste e capacidade, mesmo quando outra nuvem é usada.

Exclusão acidental ou ransomware

Réplica síncrona copia rapidamente a exclusão. A defesa exige histórico separado, retenção, imutabilidade quando aplicável e identidade administrativa isolada. A restauração deve ocorrer num ambiente que não sobrescreva a única cópia restante. Chaves de criptografia fazem parte da recuperação: dado cifrado sem chave recuperável equivale a dado perdido.

Corrupção silenciosa

Checksum ajuda, mas não prova regra de negócio. Um backup pode restaurar tecnicamente e conter OS sem responsável, eventos duplicados ou referências quebradas. Valide integridade estrutural e invariantes do domínio, depois execute um teste ponta a ponta.

ERP indisponível

Não prenda a transação local à disponibilidade remota se o negócio aceita convergência posterior. Grave a conclusão e um evento de saída na mesma transação; um worker entrega ao ERP com idempotência. A interface mostra pending_erp em vez de mentir “tudo concluído”. Se a política exige confirmação síncrona, essa dependência precisa entrar no RTO da jornada.

Caso completo: OS confirmada, ERP pendente

O eletricista envia a conclusão com uma chave de idempotência. A API autentica, autoriza, valida o estado e persiste a mudança junto com um item de outbox. A resposta confirma o estado local e informa sincronização pendente. Se o ERP cair, a fila retém a intenção; se a API cair após o commit, a repetição com a mesma chave retorna o resultado lógico anterior. Após desastre, a equipe restaura banco e outbox ao mesmo ponto, inicia workers de modo controlado e reconcilia com o ERP.

Esse desenho não resolve tudo. Se o ERP executou o efeito e a confirmação se perdeu, o worker precisa consultar estado ou usar uma chave reconhecida pelo ERP. Se apenas o banco for restaurado, mas mensagens posteriores ainda estiverem na fila externa, eventos “do futuro” podem reaparecer. O runbook precisa ordenar contenção, restauração e retomada.

Segurança, privacidade e custo de recuperação

Backups são alvos valiosos porque concentram histórico e dados pessoais. Aplique menor privilégio, criptografia em trânsito e repouso, credenciais separadas, auditoria e testes de acesso. Evite registrar payload integral durante o restore; use identificadores e contagens. Políticas de retenção precisam conciliar recuperação, obrigações legais e exclusão: guardar indefinidamente “por segurança” aumenta exposição.

Um atacante com permissão de apagar produção não deveria apagar todas as cópias com a mesma identidade. Imutabilidade e separação administrativa reduzem esse risco, mas exigem um processo autorizado de expiração. Teste também o cenário de credencial comprometida e preserve evidência do incidente.

Custos incluem armazenamento, transferência, ambiente de contingência, licenças, tempo de engenharia e horas de plantão. Um segundo ambiente permanentemente ativo pode reduzir RTO, mas aumentar superfície de ataque e risco de configuração divergente. O controle correto é aquele que atende o impacto com operação sustentável.

Diagnóstico guiado por evidência

Sintoma	Hipótese	Evidência a coletar	Próxima ação segura
réplica não assume	health check, quorum ou credencial	eventos de eleição e dependências	degradar escrita e evitar dois primários
restore termina, aplicação falha	versão, segredo ou migração incompatível	logs sanitizados, schema e manifestos	restaurar conjunto coerente
dado apagado reaparece	fila externa posterior ao ponto restaurado	offsets e IDs idempotentes	pausar consumidores e reconciliar
backup “verde” não abre	job copiou, mas não validou	checksum, catálogo e teste de leitura	bloquear aprovação e restaurar cópia anterior
RTO excedido	dependência ou passo manual esquecido	linha do tempo do game day	automatizar o gargalo comprovado

Não comece por “qual serviço está vermelho?”. Comece por “qual jornada falhou, desde quando e qual estado foi confirmado?”. Correlation IDs, logs, métricas e traces ajudam a reconstruir o caminho, mas precisam sobreviver de forma segura ao mesmo domínio de falha.

Critérios de aceite

• Jornadas possuem owner, impacto, RTO, RPO e modo degradado aprovados.
• Diagrama inclui banco, fila, identidade, segredos, DNS, ERP e observabilidade.
• Cada réplica está associada a um domínio de falha conhecido.
• Backup possui retenção, criptografia, catálogo, imutabilidade quando necessária e identidade separada.
• Restore foi executado em ambiente isolado e validou integridade mais jornada ponta a ponta.
• RTO e RPO observados ficaram dentro dos objetivos; divergências geraram ação e responsável.
• O runbook define declaração, contenção, ordem de recuperação, comunicação, validação e retorno.
• O game day inclui pelo menos falha de instância, indisponibilidade de dependência e exclusão/corrupção.
• A retomada de filas é idempotente e reconciliada com o ERP.

Exercício guiado e desafio

Exercício: escolha três jornadas do sistema de manutenção. Produza a matriz de impacto, um diagrama de dependências e uma tabela que relacione falha, detecção, contenção, recuperação e evidência. Para a OS 742, explique por que uma réplica não recupera uma exclusão já replicada.

Entregável verificável: matriz aprovada, diagrama, manifesto do backup, saída de um restore, duração medida, ponto recuperado e resultado de um teste E2E. Outra pessoa deve conseguir repetir o procedimento sem orientação oral.

Desafio: simule a restauração do banco para 10:00 enquanto a fila contém eventos produzidos até 10:05. Desenhe como impedir duplicação ou reintrodução de estado incompatível. Compare duas estratégias e registre o trade-off entre perda, complexidade e tempo.

Recuperação ativa

1. Qual diferença entre disponibilidade e durabilidade?
2. Por que duas instâncias podem continuar sendo um único ponto de falha?
3. O que RTO e RPO não garantem sozinhos?
4. Como provar que um backup é recuperável?
5. Em qual ordem você pausaria filas, restauraria dados e retomaria o ERP?

Transição

Agora que o modelo mental está definido, o caderno operacional transforma os objetivos em um ensaio local reproduzível. Mais adiante, o livro de APIs, contratos e integrações mostra como idempotência, estados pendentes e reconciliação preservam a jornada quando o ERP falha.

Fontes oficiais

• NIST SP 800-34 Rev. 1 — Contingency Planning Guide
• PostgreSQL — Backup and Restore
• PostgreSQL — Continuous Archiving and Point-in-Time Recovery
• AWS Well-Architected — Reliability Pillar
• Google SRE — Availability Table
• OpenTelemetry — Concepts

Revisão editorial: 2 de agosto de 2026. Metas e configurações de fornecedores são voláteis; confirme a documentação da versão implantada e preserve a evidência do teste local.

Da compreensão à execução

O modelo anterior explica o que precisa permanecer verdadeiro. Agora o caderno transforma essa compreensão em um experimento. Antes de executar, escreva sua previsão; depois compare o observado com o esperado e registre a primeira fronteira onde o estado divergiu.

Missão do laboratório

Você será responsável por recuperar uma fatia pequena, porém completa, do sistema de manutenção. Às 10:00, o eletricista conclui a OS 742. A API persiste o novo estado e cria um evento de integração. Às 10:07, o ERP ainda não confirmou. Às 10:12, uma exclusão administrativa remove a OS e replica para a cópia de leitura. O objetivo não é “subir um banco”; é voltar a uma situação em que:

• a OS confirmada pode ser consultada;
• o histórico e a auditoria permanecem coerentes;
• a integração pendente não é executada duas vezes;
• o usuário enxerga um estado honesto;
• o tempo e o ponto recuperados atendem ao contrato.

Use somente ambiente local ou sandbox e dados sintéticos. Não copie credenciais, dumps ou logs de produção. Se seu computador não dispõe de PostgreSQL, execute a parte de planejamento e o verificador com um conjunto simulado; registre essa limitação. Um laboratório honesto não finge ter testado a tecnologia ausente.

O que será produzido

Ao final, a pasta de evidências — fora do conteúdo canônico — deve conter:

recovery-drill-742/
├── scope.md                 jornada, início/fim e exclusões
├── dependency-map.mmd      diagrama editável
├── recovery-contract.yaml  RTO, RPO, owners e gates
├── backup-manifest.json    origem, horário, hash e versão
├── commands.log            comandos sem segredos
├── validation.txt          checks estruturais e E2E
├── timeline.csv            detecção até encerramento
├── runbook.md              procedimento corrigido
└── report.md               resultado, falhas e ações

Esses arquivos são a evidência. Screenshot isolada de um console verde não informa qual dado voltou, quanto demorou ou se a jornada funciona.

Passo 0 — fixe segurança e condição de parada

Defina um diretório temporário exclusivo, uma instância descartável e credenciais próprias do laboratório. Confirme visualmente o host antes de qualquer comando de restauração. Proíba comandos destrutivos contra caminhos amplos, bancos compartilhados ou nomes calculados sem validação. A condição de parada é imediata se o destino não puder ser distinguido de produção.

O operador do restore não deve usar a mesma credencial que exclui backups. O relatório não contém token, senha, string de conexão completa nem dados pessoais. Quando o exercício termina, revogue a credencial temporária e elimine os dados sintéticos pelo mecanismo autorizado do ambiente.

Passo 1 — escreva o contrato antes de medir

Defina o relógio e o significado dos objetivos. Neste laboratório:

jornada: concluir e consultar OS 742
inicio_rto: declaração do incidente
fim_rto: teste E2E consulta OS e integração fica reconciliável
rto_max_minutes: 60
rpo_max_minutes: 15
ponto_do_desastre: "2026-08-02T10:12:00-03:00"
modo_degradado: consulta somente leitura e fila manual numerada
owner_negocio: supervisão de manutenção
owner_tecnico: plantonista da aplicação
gate_dados: OS, auditoria e outbox coerentes

Um RPO de quinze minutos permite recuperar até 09:57 para um desastre às 10:12. Mas o negócio pode classificar a conclusão crítica como perda inaceitável. Nesse caso, o contrato precisa de uma exceção por dado ou de um mecanismo mais forte. Não ajuste o objetivo depois de conhecer o resultado.

Passo 2 — desenhe dependências e ordem de retomada

sequenceDiagram
  actor O as Operador
  participant G as Gateway/API
  participant D as Banco restaurado
  participant Q as Outbox/worker
  participant R as ERP
  O->>G: ativa modo de recuperação
  O->>Q: pausa consumo
  O->>D: restaura ponto escolhido
  O->>D: valida schema e invariantes
  O->>G: executa consulta E2E
  O->>R: consulta estado da OS 742
  O->>Q: reconcilia e retoma com limite
  Q->>R: envia com chave idempotente
  R-->>Q: estado conhecido

Pause produtores e consumidores antes de combinar estado restaurado com eventos mais novos. Inclua identidade, DNS, segredos, armazenamento, observabilidade e contato do ERP no mapa. Para cada dependência, registre: owner, timeout, fallback, dado necessário, sinal de saúde e procedimento quando indisponível.

Passo 3 — prepare uma história verificável

Crie dados sintéticos com IDs previsíveis:

horário	entidade	mudança esperada
09:50	OS 741	permanece aberta
10:00	OS 742	concluída, pending_erp
10:05	auditoria 742	registra ator sintético e transição
10:07	outbox 742	tentativa 1 com chave os-742-complete-v1
10:12	incidente	exclusão da OS 742

O manifesto do backup registra horário inicial/final, origem, versão do banco, método, tamanho, checksum, criptografia, retenção e software necessário para restaurar. Um hash confirma igualdade de arquivo, não consistência do conteúdo; por isso haverá validação posterior.

Para PostgreSQL, escolha conscientemente entre dump lógico, backup físico e recuperação para um ponto no tempo. A documentação oficial de Backup and Restore e Continuous Archiving descreve capacidades e restrições. Não misture comandos de métodos diferentes como se fossem equivalentes.

Passo 4 — capture o baseline

Antes da falha, prove a jornada:

1. consulte a OS 742 e guarde apenas a saída sintética necessária;
2. confirme exatamente um evento de auditoria;
3. confirme uma entrada de outbox com chave idempotente;
4. execute a consulta pela API, não apenas diretamente no banco;
5. registre correlation ID e duração;
6. exporte o manifesto e verifique o checksum.

O teste pelo banco prova persistência; o teste pela API prova parte da jornada. Se autenticação ou segredo do ambiente de recuperação não funciona, o restore ainda não terminou.

Passo 5 — injete as falhas

Injete duas falhas separadamente:

Falha A — continuidade: torne uma instância da API indisponível. Meça o momento em que a jornada falha, o health check detecta e outra instância assume. Se ambas usam a mesma dependência caída, documente o domínio comum em vez de declarar failover bem-sucedido.

Falha B — história: exclua a OS 742 no banco descartável e confirme que a exclusão chega à réplica de leitura. Isso demonstra por que réplica não é backup. Em seguida, marque a declaração do incidente e inicie o cronômetro do RTO.

Não crie uma corrupção impossível apenas para facilitar o exercício. O cenário deve reproduzir uma causa plausível e ter sinais observáveis.

Passo 6 — contenha antes de restaurar

Ative modo somente leitura ou bloqueie a operação afetada por feature flag. Pause o worker do ERP. Preserve logs e manifesto. Revogue a credencial que realizou a exclusão, se o cenário incluir comprometimento. Se houver suspeita de ransomware, não conecte o destino limpo ao mesmo plano de controle antes da contenção.

Escolha o ponto de recuperação com evidência. Restaurar “o backup mais recente” pode trazer corrupção já presente. Registre por que o ponto escolhido é anterior ao evento e que perda ele implica.

Passo 7 — restaure num destino novo

Crie um destino explicitamente nomeado como laboratório. Restaure sem sobrescrever origem ou única cópia. Valide, nesta ordem:

1. processo terminou sem erro;
2. versão e extensões são compatíveis;
3. schema e migrações correspondem à aplicação;
4. chaves estrangeiras e constraints estão válidas;
5. OS 741, OS 742, auditoria e outbox têm cardinalidade esperada;
6. a API inicia usando credenciais recuperáveis;
7. a consulta E2E retorna a OS 742;
8. o estado do ERP é consultado antes de reenviar.

Se o ponto restaurado precede a conclusão da OS, o RPO observado para essa jornada inclui a perda. Não recrie o dado silenciosamente e declare sucesso; registre a divergência e aplique o procedimento de reconstrução aprovado pelo negócio.

Passo 8 — calcule o gate com código executável

O verificador a seguir é TypeScript válido e não acessa infraestrutura. Ele transforma a linha do tempo do ensaio em uma decisão determinística:

type Drill = {
  incidentDeclaredAt: string;
  journeyRecoveredAt: string;
  disasterAt: string;
  recoveredPointAt: string;
  rtoMaxMinutes: number;
  rpoMaxMinutes: number;
};

const minutesBetween = (later: string, earlier: string) =>
  (Date.parse(later) - Date.parse(earlier)) / 60_000;

export function evaluateDrill(drill: Drill) {
  const rtoObserved = minutesBetween(
    drill.journeyRecoveredAt,
    drill.incidentDeclaredAt,
  );
  const rpoObserved = minutesBetween(drill.disasterAt, drill.recoveredPointAt);
  if (rtoObserved < 0 || rpoObserved < 0) throw new Error("linha do tempo inválida");
  return {
    rtoObserved,
    rpoObserved,
    approved:
      rtoObserved <= drill.rtoMaxMinutes &&
      rpoObserved <= drill.rpoMaxMinutes,
  };
}

console.log(evaluateDrill({
  incidentDeclaredAt: "2026-08-02T10:15:00-03:00",
  journeyRecoveredAt: "2026-08-02T10:57:00-03:00",
  disasterAt: "2026-08-02T10:12:00-03:00",
  recoveredPointAt: "2026-08-02T10:00:00-03:00",
  rtoMaxMinutes: 60,
  rpoMaxMinutes: 15,
})); // { rtoObserved: 42, rpoObserved: 12, approved: true }

Compile com o TypeScript do projeto ou copie o algoritmo para o runtime permitido. Acrescente testes para limite exato, data inválida e linha do tempo invertida. O resultado approved: true não basta: os checks da jornada também precisam passar.

Passo 9 — reconcilie e retome gradualmente

Consulte o ERP usando a chave os-742-complete-v1. Se o efeito já existe, marque a outbox como entregue sem repetir. Se não existe, envie uma única vez e registre a confirmação. Reative consumidores com taxa limitada, observe lag, duplicatas, erros e saturação. Só retire o modo degradado depois que banco, fila, API e ERP convergirem.

A retomada é um deploy operacional e merece canário. Uma fila acumulada pode derrubar o ERP logo após a “recuperação”. Backpressure e limites protegem a dependência.

Telemetria e diagnóstico

Use logs estruturados, métricas e traces conforme os conceitos do OpenTelemetry. Redija dados sensíveis antes da exportação.

Sintoma	Hipótese	Verificação	Correção segura
restore rápido, E2E falha	segredo ou schema incompatível	versão, migração e trace	recuperar configuração compatível
RPO nominal 5 min, observado 40	job atrasado ou cópia inválida	timestamps e manifesto	alertar sobre idade e testar ponto
ERP recebe duplicata	estado remoto desconhecido	chave e consulta de estado	reconciliar antes do retry
dados somem após retomada	evento posterior ao restore	offset, horário e correlation ID	pausar e reordenar/reprocessar
somente um tenant falha	ACL ou dado específico	caso sintético por tenant	corrigir policy sem abrir acesso

Runbook mínimo

O runbook deve dizer quem declara o incidente, como confirmar o destino, quais componentes pausar, como selecionar o ponto, comandos aprovados, validações, critérios para abortar, contatos, comunicação aos usuários, retomada e escalonamento. Inclua o tempo esperado por etapa e um caminho quando o ERP não responde.

Durante o game day, uma pessoa executa, outra injeta a falha e uma terceira registra a linha do tempo. O autor do runbook não deve sussurrar passos ausentes. Toda dúvida operacional vira melhoria concreta.

Critérios de aceite

• Ambiente e dados são sintéticos, isolados e inequivocamente não produtivos.
• RTO, RPO, início, fim, owner e modo degradado foram definidos antes do ensaio.
• A exclusão atingiu a réplica e demonstrou que ela não substitui backup.
• Restore ocorreu em destino novo e validou schema, integridade, API e consulta E2E.
• RTO e RPO observados foram calculados por dados da linha do tempo.
• O ERP foi consultado antes de retry e recebeu no máximo um efeito lógico.
• Segredos e dados pessoais não aparecem nas evidências.
• A retomada foi gradual, observada e reversível.
• Outra pessoa repetiu o runbook sem instrução oral.

Exercício, desafio e transferência

Exercício principal: execute o roteiro com OS sintéticas e entregue os nove artefatos. Marque cada critério como aprovado ou bloqueado e anexe a evidência exata.

Desafio: reduza o RTO de 60 para 20 minutos sem alterar o RPO. Identifique o gargalo medido, proponha automação apenas para ele e estime custo, risco e rollback. Não aceite “usar uma nuvem maior” sem relação causal.

Transferência: substitua o ERP por gateway de pagamento. Explique por que consulta de estado e idempotência se tornam ainda mais importantes. Depois substitua a OS por sensor offline e discuta ordenação, relógios e sincronização tardia.

Recuperação ativa

1. Por que o relógio do RTO termina no E2E e não no processo de banco?
2. O que deve ser pausado antes de combinar uma fila nova com banco antigo?
3. Qual evidência distingue checksum válido de restauração válida?
4. Quando um retry é perigoso?
5. Que passo do runbook mais consumiu tempo e como você sabe?

Transição

O ensaio mostrou que continuidade depende de contratos temporais e efeitos repetíveis. O próximo livro, APIs, contratos e integrações, aprofunda como representar pending_erp, idempotência, erros e evolução compatível na fronteira entre sistemas.

Fontes oficiais

• NIST SP 800-34 Rev. 1
• PostgreSQL — Backup and Restore
• PostgreSQL — Point-in-Time Recovery
• OpenTelemetry — Concepts
• Google SRE Workbook — Non-Abstract Large System Design

Revisão editorial: 2 de agosto de 2026. Adapte comandos ao sistema gerenciador e à versão realmente usados; o relatório deve registrar essa versão.