420Docs context
Skip to content

420Storage backup, restore and disaster recovery qualification

SR-10.6 defines how operators back up and restore the storage subsystem without turning backup media into protocol authority.

Authority boundary

Backup artifacts are operational evidence only. They may preserve service restart state, topology fingerprints and immutable manifest identity fingerprints. They must not become a replacement source of truth for storage agreements, placements, proofs, balances, settlement or authorization.

After restore, current canonical chain/manifests/placements remain authoritative. A backup that disagrees with current canonical identity fails reconciliation instead of rewriting history.

Backup contents

The qualified storage-dr-v1 artifact records:

  • capture time;
  • topology/configuration fingerprint;
  • manifest ID, object ID and manifest hash;
  • a deterministic fingerprint over immutable shard identity, including agreement, commitment and node placement identifiers;
  • derived provider/node/service lifecycle state.

Raw payload bytes, decryption keys, bearer tokens, service credentials and caller sessions are outside this artifact.

Restore procedure

  1. Provision the qualified target topology.
  2. Record the target topology fingerprint.
  3. Load the most recent available storage-dr-v1 artifact.
  4. Query current canonical manifests and placements.
  5. Recompute each manifest identity fingerprint.
  6. Reject restore if any manifest, shard, agreement, commitment or node identity differs.
  7. Reject restore if the target topology fingerprint does not match the qualified backup target.
  8. Verify measured backup age is inside the declared recovery point objective.
  9. Verify measured recovery duration is inside the declared recovery time objective.
  10. Start operational services from reconciled state; do not recreate canonical history from backup media.

Provider loss and repair reconstruction

Provider loss is handled by the existing 420Repair path. Recovery must use live qualified shards and the canonical repair plan, validate reconstruction output against the expected shard root and size, and create replacement provider/capacity/commitment/placement state through the canonical repair lifecycle.

Do not edit the backed-up placement so that a replacement node appears to have been the original provider. Historical agreement and commitment identity remains intact.

RPO and RTO evidence

SR-10.6 treats RPO and RTO as measured qualification evidence:

  • RPO is the maximum permitted age of the backup artifact at restore time.
  • RTO is the maximum permitted measured recovery duration.

The restore reconciler fails closed if either bound is exceeded. Deployment-specific production targets are established with operator SLOs in SR-10.8; this phase establishes the enforceable evidence model.

Disaster-recovery drill

A qualification drill should capture one backup, remove or fail one provider, provision the target topology, reconcile the backup against canonical manifests, reconstruct any required shard through 420Repair, retrieve and integrity-check the object, and record backup age plus recovery duration.

The drill passes only when object/manifest/shard/commitment identity remains unchanged and no backup artifact fabricates canonical state.