Backup & Recovery

Recovery must restore authoritative continuity, not merely restore files. A successful campaign re-verifies identities, signatures, rights, evidence and semantic/content roots after state destruction or replacement.

Back up separately

• Identity manifests and protected private/recovery material.
• ENTITY mutable databases/state.
• BTDU/ADAM state where deployed.
• Content/evidence vaults.
• Profiles/configuration required to interpret state.
• Release/tag/manifests needed to identify the software semantics.

Destructive recovery procedure

1. Capture pre-recovery state tree/semantic/content roots and verification results.
2. Create and hash the backup/export.
3. Remove or quarantine the mutable working state.
4. Restore into a clean destination.
5. Recompute roots.
6. Load and verify Entity manifests.
7. Reverify evidence, rights/passports and canonical lineage.
8. Perform a controlled signing operation to prove restored sovereign signing capability.
9. Record exact-match results and deviations.

v3.4.2 evidence

The release states protected-state recovery PASS, exact restore true and restored sovereign signing true. That is release evidence for the tested campaign; operators should still test their own backup media, permissions, key protector and disaster-recovery environment.

Do not overwrite evidence

Keep the backup hash, test report, pre/post roots and failure logs. A recovery test that only reports “worked” without preserving comparable roots is weaker evidence.