LEARN. PRACTICE. GROW.Define the recovery contract
The lab contains fictional payments, each with a positive amount and two postings. Its contract requires exactly one debit and one credit of the same amount. This deliberately simple rule separates structural integrity, referential integrity and business consistency. Before execution, write the observation you would accept for each condition. A file's existence, readable tables and a responding process are different evidence. The final p1-through-p4 list is supplied by the exercise; it is not confirmation obtained from a payment system. In real operations, that reference would need its own origin, time scope and authority. The exercise teaches how to formulate that requirement without pretending to have established it against an external system.
Compare snapshots before and after commit
The script opens separate SQLite connections. The writer begins a transaction and creates only part of the third payment. The backup connection observes the two committed payments and should not include half of the third. After both postings are committed, another backup contains the complete third payment. Compare identifiers and reconciliation failures in the results. The earlier copy retains its content even though the source advances. This exercise uses WAL and the backup API in the recorded environment. It does not establish that copying only the main file of an active database is safe, or measure behavior under continuous writes, power loss or exhausted storage.
Distinguish checks that can pass together
An extra posting row can be valid SQL and still reference an existing payment. Structural and referential checks therefore pass while the business rule fails. The report identifies p3 as inconsistent. In a second file, the exercise explicitly disables foreign-key enforcement to introduce a nonexistent reference; integrity_check still passes, but foreign_key_check finds the problem. These are controlled fault injections into fictional data, not instructions for repairing production. Recovery decisions should use controls appropriate to the intended outcome. Repeating the same structural check more often does not replace checking a property that it does not assess. Preserve the differing results in the acceptance record instead of reporting one undifferentiated integrity status.
Interpret the digest and its reference
The script records a completed copy's digest and compares another copy with that reference. After a payment amount changes, the match fails. Computing a new reference over the altered file, however, matches those changed bytes. Reconciliation still fails because recalculating a hash does not repair the application. To use this result in a decision, identify who captured the reference, when and under what protection. The lab retains the reference in the same process and trust context; it does not demonstrate independent authentication, immutable storage or evidentiary admissibility. Those limits do not make comparison useless: they define what can be claimed from it. Keep byte equality and approved business state as separate acceptance conditions.
Observe where fallback changes its nature
Run the column-renaming migration while its transaction remains open. The old query fails, but rollback restores the previous schema. Then observe a committed migration: returning to code that reads the old name does not reverse the database. The script also adds a column without removing existing ones and checks an explicitly defined query. That compatibility is local and limited. Do not conclude that every client works, especially where reading patterns or data meaning differ. When preparing a change, decide which versions coexist, how transition is validated and which persisted state each fallback option leaves behind. Evidence about a reversible open transaction does not establish reversibility after the release has committed changes.
Reconcile accepted work and communicate the limit
The final part restores the copy ending at p3 and compares it with the required p1-through-p4 set. Structural and reference checks pass, but work is missing under the exercise's contract. The script adds p4 with both postings and checks the set and amounts again. A subsequent attempt to insert the same key is rejected and rolled back. This demonstrates local key and transaction behavior, not idempotence of external effects. Two runs retained 33 checks and removed temporary files. Use that evidence to explain the performed exercise without converting it into a guarantee of RTO, real-system integrity or readiness to reopen a banking application. Identify which additional acceptance evidence would be needed.
cd content/labs/cissp-operations-contracts
python3 recovery_release_lab.py --output learner-run.jsonA backup opens without errors and all references exist, but one payment has two debits. Recovery requires business-rule reconciliation before acceptance.
Common pitfalls
Confusing a readable file with correct business state; treating a recomputed digest as a fix; treating code rollback as data reversal; generalizing a local rehearsal to production.
Related topics: Operations and recovery · Software and supply chain · Assessment and evidence
Accepting recovery requires explicit criteria, checks that actually assess them and an honest account of the rehearsal limits.
Reference: Guide for Cybersecurity Event Recovery · CISSP outline effective April 15, 2024; current AI guidance consulted 2026-09-29