LEARN. PRACTICE. GROW.Restore without depending on the source
The runner closes and removes the original synthetic database before the restore experiment. It copies the API-produced artifact to another path and starts a new Python process to open it with mode=ro. That option requires the file to exist and avoids silently creating an empty database at an incorrect path. The probe calculates results through a fresh connection, and the runner compares the artifact hash before and after. The accepted example contains the two expected entries, total 125, and sequence 2. This procedure demonstrates reading and validating the copy without the original file. It does not recover enterprise configuration, credentials, encryption keys, or external services. The runtime remains available. Controlled file removal is not equivalent to losing a datacenter or cutting storage power.
Use checks that answer different questions
The probe combines five conditions. integrity_check evaluates structural aspects of the database; foreign_key_check looks for referential violations excluded from the first check. The synthetic application must support the user_version marker. The sum of batch entries must match the declared total. The highest sequence must reach the supplied requirement. The ready result requires every condition rather than a majority. The lab separately introduces three defects into disposable copies: an incorrect total, an entry with a nonexistent batch_id, and an unsupported version marker. All three artifacts continue passing the structural check but fail their specific criterion. In this fixture, changing the marker tests only a probe compatibility rule; it does not perform an actual schema migration. Preserve that distinction when reporting results.
Preserve evidence during the decision
A functional discrepancy does not authorize changing data until the probe passes. If entries sum to 125 while the declared total is 999, there may be an incorrect total, missing entries, or an unsuitable reference. The lab deliberately creates the first defect, but an operator of a real application needs evidence to distinguish causes. Preserve the artifact, record the failed check, and reconcile against an authorized reference. During migration, the old copy may also be correct at its own point while omitting operations already accepted at the new destination. Rollback requires controlling write authority and deciding how to address that interval. Keeping two destinations open to independent changes can widen divergence. The technical manager should expose uncertainty, ownership, and the next decision criterion alongside the recovery deadline.
Prepare RUN autonomy and acceptance
Give RUN a procedure for locating the required point, confirming dependencies, restoring, interpreting the probe, and escalating uncertain outcomes. The guide below proposes forty minutes of practice and discussion. Its code was executed automatically with CPython 3.13.1, SQLite 3.51.2, and Darwin 27.0.0 arm64, but the workshop has not yet been performed with participants. Nine observations and 24 checks document the local fixture; they measure neither enterprise RPO or RTO nor performance under load. For a real application, add supported versions, access, keys, external files, dependent services, write authority, and business-workflow criteria. Define who can accept a technical phase and who accepts the complete service. A backup that opens is a useful milestone; closure depends on coverage actually demonstrated.
40-MINUTE GUIDE
0–8: Save the previous lesson's complete code as run.py in an authorized local folder. The executed reference uses Python 3.13.1 and SQLite 3.51.2. It needs no real database, network, administrator privileges, or external dependencies.
python3 run.py --output./storage-recovery-evidence.json
8–18: Confirm nine groups, eight probe subprocesses, and 24 checks. Compare mainOnly and onlineBackup: readability, sequence, and total. Explain why the main file can remain unchanged after COMMIT in WAL mode. The runner removes only its temporary files, including the synthetic source.
18–30: Compare uncommittedExcluded, laterCommit, restored, businessDefect, foreignKeyDefect, and unsupportedVersion. Identify the failed criterion in each copy. Do not convert a sequence difference into minutes without timestamps.
30–40: Write a recovery handover with required point, copy method, dependencies, probe, evidence, escalation, and acceptance authority. Record that the fixture excludes real load, keys, networking, Oracle/DB2, power failure, and complete business workflows. Repeat with a different output name to preserve earlier reports.Lago can open its backup, but the sum of entries differs from the declared total. Recovery remains unaccepted pending authorized reconciliation.
Common pitfalls
Accepting by a majority of checks, treating user_version changes as migration, adjusting totals merely to obtain green status, or confusing a read probe with every production workflow.
Related topics: RUN handover · Migration and write authority
Functional recovery requires the complete set of agreed criteria. Retain failure evidence and resolve its cause before changing acceptance status.
Reference: Original synthetic application recovery fixture using sqlite3 · BigSavant Storage 2026-09; selected Linux and AWS storage behavior