APRENDER. PRATICAR. EVOLUIR.Definir a referência antes de restaurar
O laboratório usa uma aplicação fictícia com duas ordens, de 100 e 200 unidades, para o dia de negócio 2026-10-02. Cada ordem tem linhas cujo total deve coincidir com o seu montante. Estes valores são a referência do exercício e ficam definidos fora da cópia que será avaliada. Se a referência fosse calculada apenas a partir dos dados restaurados, uma ordem perdida desapareceria também do resultado esperado. No trabalho de APS, identifica o controlo independente disponível: identificadores aceites, totais de entrada ou confirmação do processo anterior. Documenta o âmbito, a data de negócio e a origem dessa referência antes de interpretar um relatório verde.
Uma cópia incompleta pode continuar legível
No primeiro exercício, a ordem inicial é confirmada e o laboratório executa um checkpoint. Depois confirma a segunda ordem, mantendo a ligação aberta e a escrita em WAL. Copia deliberadamente apenas o ficheiro principal para demonstrar um método inadequado nestas condições. A origem tem duas ordens, mas essa cópia contém uma; integrity_check devolve ok. Uma cópia obtida pela API de backup contém ambas. O resultado não é uma recomendação para copiar ficheiros ativos manualmente. É uma observação controlada de como uma verificação pode passar sobre um ponto anterior. Regista em separado a integridade do artefacto e a cobertura dos compromissos que se pretendia recuperar.
Separar trabalho em curso de compromissos confirmados
O segundo exercício abre uma transação e insere uma terceira ordem. O writer vê três, enquanto o backup feito por uma ligação separada contém duas. A transação original termina com rollback. Esta diferença é esperada: a terceira ordem nunca foi confirmada para aquele leitor. A ligação usada no backup não é a mesma que mantém a escrita por confirmar. A distinção interessa quando alguém compara um ecrã de uma sessão aberta com um artefacto recuperado. Antes de concluir perda de dados, identifica se a operação foi confirmada, qual o ponto observado e que evidência pertence à transação. O laboratório não simula uma falha de energia nem mede garantias de armazenamento físico.
Controlar artefacto, âmbito e destino
O guard local compara o hash de um backup fechado com um valor esperado de confiança. Um ficheiro truncado é recusado antes de criar o destino. Outro ensaio usa bytes válidos, mas um âmbito diferente: exercise-a não pode ser aceite como exercise-b. Um terceiro caminho encontra um destino existente e conserva-o intacto. São três perguntas distintas: recebemos o artefacto esperado, pertence ao âmbito pretendido e podemos usar este destino? O digest não autentica sozinho um ficheiro se o atacante também puder substituir o valor esperado. O código assume um diretório temporário privado, ficheiros estáveis e ausência de mudanças concorrentes de caminhos; não é uma ferramenta de restauro para sistemas hostis.
Verificar referências e regras de negócio
O laboratório cria dois defeitos em cópias descartáveis. Na primeira, insere uma linha com uma referência inexistente, desativando deliberadamente a proteção só para construir o contraexemplo. integrity_check passa e foreign_key_check encontra uma violação. Na segunda, as referências são válidas, mas as linhas da ordem de 200 somam 190. Ambos os controlos técnicos passam e a reconciliação de montantes falha. A aceitação exige controlos que correspondam ao contrato dos dados. Não ajustes o valor apenas para passar o teste: conserva a diferença, procura a fonte autorizada e volta a ensaiar uma correção aprovada. Uma base legível pode continuar imprópria para produzir o ficheiro de fecho.
Reproduzir e limitar a conclusão
O ficheiro run.py cria todas as bases numa pasta temporária e não recebe caminhos para bases existentes. A evidência publicada regista Python 3.13.1 e SQLite 3.53.4. A versão SQLite usada é posterior à correção de WAL descrita na documentação; o exercício não tenta reproduzir essa condição de corrida. Oito grupos verificam operações locais e o hash do script associa a evidência ao código ensaiado. Nenhum resultado demonstra recuperação PostgreSQL, Oracle, cloud ou failover real. Para transferir a aprendizagem para um projeto, define os mecanismos da tecnologia efetiva e repete controlos equivalentes num ambiente autorizado. Conserva versão, dados esperados, resultados e limites junto do relatório de aceitação.
python3 content/labs/recovery-restore/run.py
# Requires SQLite >= 3.51.3; recorded run: Python 3.13.1 / SQLite 3.53.4
# All databases are disposable local fixtures.A origem tem duas ordens. Uma cópia apenas do ficheiro principal tem uma e passa integrity_check; a cópia pela API tem duas. O ponto recuperado tem de ser verificado separadamente.
Armadilhas comuns
Calcular a referência apenas a partir do restore; copiar apenas o principal em WAL; tratar um digest como autorização; corrigir montantes sem fonte de negócio.
Tópicos relacionados: Retoma: replay e aceitação operacional · RTO, RPO e dependências · Ensaios e validação funcional
Aceita um restauro pelo ponto e pelo contrato dos dados, com verificações complementares e evidência reproduzível.
Referência: SQLite Backup API · DR recovery 2026-09; PostgreSQL 18, etcd 3.6 and selected AWS/Azure behavior