APRENDER. PRATICAR. EVOLUIR.Restaurar sem depender da origem
O runner fecha e remove a base original sintética antes do ensaio de restauro. Copia o artefacto produzido pela API para outro caminho e lança um novo processo Python para o abrir em mode=ro. Essa opção exige que o ficheiro exista e evita criar silenciosamente uma base vazia num caminho errado. A sonda calcula resultados através de uma nova ligação e o runner compara o hash do artefacto antes e depois. O exemplo aceite contém as duas entradas esperadas, total 125 e sequência 2. Este procedimento demonstra leitura e validação da cópia sem o ficheiro original. Não recupera configuração empresarial, credenciais, chaves de encriptação ou serviços externos. O ambiente de execução continua disponível. A remoção controlada de um ficheiro não equivale a perder um datacenter ou a cortar energia ao armazenamento.
Usar verificações que respondem a perguntas distintas
A sonda combina cinco condições. integrity_check avalia aspetos estruturais da base; foreign_key_check procura violações referenciais que o primeiro controlo não inclui. O marcador user_version tem de ser suportado pela aplicação sintética. A soma das entradas do lote tem de coincidir com o total declarado. A maior sequência tem de atingir o requisito fornecido. O resultado ready exige todas as condições; não funciona por maioria. O laboratório introduz separadamente três defeitos em cópias descartáveis: total errado, entrada com batch_id inexistente e marcador de versão não suportado. Os três artefactos continuam a passar a verificação estrutural, mas falham o critério específico. Na fixture, alterar o marcador testa apenas uma regra de compatibilidade da sonda; não executa uma migração real de esquema. Conserva essa distinção no relatório.
Preservar evidência durante a decisão
Uma divergência funcional não autoriza alterar dados até a sonda passar. Se a soma for 125 e o total declarado 999, pode existir um total incorreto, entradas em falta ou uma referência inadequada. O laboratório cria intencionalmente o primeiro defeito, mas o operador de uma aplicação real precisa de evidência para distinguir as causas. Preserva o artefacto, regista a falha e reconcilia com uma referência autorizada. Numa migração, a cópia antiga também pode estar correta no seu ponto e omitir operações já aceites no novo destino. Uma reversão exige controlar a autoridade de escrita e decidir como tratar esse intervalo. Manter dois destinos a aceitar alterações independentes pode ampliar a divergência. O gestor técnico deve tornar visíveis a incerteza, o responsável e o próximo critério de decisão, além do prazo de recuperação.
Preparar autonomia e aceitação do RUN
Entrega ao RUN um procedimento que permita localizar o ponto necessário, confirmar dependências, restaurar, interpretar a sonda e escalar resultados incertos. O guião abaixo propõe quarenta minutos de prática e discussão. O código foi executado automaticamente com CPython 3.13.1, SQLite 3.51.2 e Darwin 27.0.0 arm64, mas a oficina ainda não foi realizada com participantes. As nove observações e 24 verificações documentam a fixture local; não medem RPO ou RTO empresarial nem performance sob carga. Para uma aplicação real, acrescenta versões suportadas, acessos, chaves, ficheiros externos, serviços dependentes, autoridade de escrita e critérios dos fluxos de negócio. Define quem pode aceitar uma fase técnica e quem aceita o serviço completo. Um backup que abre é um marco útil; o fecho depende da cobertura efetivamente demonstrada.
GUIÃO DE 40 MINUTOS
0–8: Guarda o código completo da aula anterior como run.py numa pasta local autorizada. A referência executada usa Python 3.13.1 e SQLite 3.51.2. Não precisa de uma base real, rede, privilégios de administrador ou dependências externas.
python3 run.py --output ./storage-recovery-evidence.json
8–18: Confirma nove grupos, oito subprocessos de sonda e 24 verificações. Compara mainOnly e onlineBackup: legibilidade, sequência e total. Explica por que o principal pode não mudar depois de COMMIT em WAL. O runner remove apenas os seus ficheiros temporários, incluindo a origem sintética.
18–30: Compara uncommittedExcluded, laterCommit, restored, businessDefect, foreignKeyDefect e unsupportedVersion. Indica o critério que falha em cada cópia. Não convertas uma diferença de sequência em minutos sem timestamps.
30–40: Escreve um handover de recuperação com ponto exigido, método de cópia, dependências, sonda, evidência, escalada e autoridade de aceitação. Regista que a fixture não cobre carga real, chaves, rede, Oracle/DB2, falha de energia ou todos os fluxos de negócio. Repete com outro nome de output para preservar os relatórios anteriores.Lago consegue abrir o backup, mas a soma das entradas diverge do total declarado. A recuperação fica por aceitar até existir reconciliação autorizada.
Armadilhas comuns
Aceitar por maioria dos controlos, mudar user_version como se fosse migração, corrigir totais apenas para obter verde ou confundir uma sonda de leitura com todos os fluxos de produção.
Tópicos relacionados: Passagem para RUN · Migração e autoridade de escrita
Recuperação funcional exige o conjunto dos critérios acordados. Conserva a evidência de falha e resolve a causa antes de alterar o estado de aceitação.
Referência: Original synthetic application recovery fixture using sqlite3 · DR Storage 2026-09; selected Linux and AWS storage behavior