Status: Accepted; full backup/restore and cluster qualification pending. Product source: sections 5–6 and 37–45; source test status is tracked by StorageRecovery and BackupRestore.
WAL/transaction journals, domain event history, queue state, subscription checkpoints, inbox outcomes, and rebuildable projections have different authority and retention. Trimming a recovery log must not silently delete public event history. A backup of one silo-local store records an internally consistent manifest and the committed cut of every authoritative resource needed to restore that state. Derived indexes may use a documented rebuild recipe. Restoring an older cut starts with delivery paused and a new store incarnation until reviewed and resumed.
Separate lifecycles prevent log compaction from changing customer-visible history and make restore scope explicit. A backup is not valid if it omits metadata required to interpret data or if it silently replays external effects. Retention pins may consume storage; physical purge across the ReplicaCount copies, snapshots and archives needs its own measured and operational contract.
StorageRecovery REQ-STORAGE-004, EventStreams REQ-EVENT-005..007, and Messaging REQ-MSG-006. Related files: StorageRecovery and BackupRestore.
- Freeze authoritative manifest, committed store cut, retention pins, event-history guarantees, paused restore, and external-effect reconciliation.
- Add real-store tests for current-format backup consistency, interruption, corruption, retention pins, restore-old-cut token invalidation, and absence of automatic dispatch.
- Implement in
src/KeyLoad.Core/Restore/andsrc/KeyLoad.Storage.ZoneTree/Restore/; each silo-local ZoneTree owner backs up and restores its own local files. - Validate the current manifest version and every resource before restore. Reject unsupported versions and preserve original archive bytes; stop dispatch if any resource/cut is unknown.
- GitHub CI runs TUnit, recovery, and replicated-cluster restore drills.
Dependencies: ADR-003, ADR-004, ADR-005, and ADR-030. Stop if any authoritative message/history state is omitted or restore would automatically invoke an external side effect.
Capture requires the complete current-format set of the store's live partition families; canonical data records remain authoritative. A partial capture is never reinterpreted as ready, and rollback preserves the original rows and withholds capture (REQ/AC-BACKUP-004 in BackupRestore).
flowchart LR
Sources[Canonical data events queue and cursor state] --> Cut[Consistent catalog and partition cuts]
Cut --> Manifest[Versioned authoritative manifest]
Manifest --> Validate[Verify resources and checksums]
Validate --> Restore[Restore paused with new incarnation]
Restore --> Review[Reconcile external outcomes]
Review --> Resume[Explicit authorized dispatch resume]