Backup and portability
Define what a complete database backup must preserve and what remains outside it.
Status: Design. A complete user-facing backup, restore and retention workflow is not accepted at this checkpoint. A log snapshot is a useful building block, not the whole product contract.
Back up the database's meaning
A restorable database includes more than current documents. It also needs the metadata that makes retries, branches and queries behave correctly.
| State | Why it matters |
|---|---|
| Records and property edges | The visible application data and relationships. |
| Schemas, indexes and catalog versions | The interpretation and constraints attached to those records. |
| Branch catalog and retained roots | The worlds that must remain readable after restore. |
| Receipts and replay identities | Prevent retries from duplicating already accepted operations. |
| Events, source progress and corrections | Preserve intake meaning and analytical contributions. |
| Ownership and format identity | Distinguish the restored store and reject unsupported formats. |
A JSON export of visible records is valuable for portability. It should not be described as a complete operational backup if it omits the other state needed to resume safely.
Pin a consistent view
The intended backup process first retains the roots or log boundary it needs. It then writes the selected immutable content with a manifest and integrity checks, publishing a complete backup only after its own durability steps succeed.
Readers, backups and branch merge bases create retention obligations. Reclaiming storage while one still depends on it would turn a successful-looking export into a damaged backup.
Restore should build into a new controlled directory, validate the whole image and preserve the original until acceptance succeeds. An incomplete staging area must never be mistaken for a fresh valid store.
Code and external effects stay separate
A database snapshot does not automatically contain Git objects, working-copy edits, untracked files or secrets. A workspace export needs an explicit manifest for any code context it includes.
Restoring old application state also cannot undo an email, payment or deployment that already occurred elsewhere. Effects require their own reconciliation rules; opening a restored world must not replay them automatically.
Prove a restore, not just a copy
Acceptance should restore into a clean location, reopen every promised branch, verify representative records and relationships, retry known requests without duplication, and confirm source/projection positions.
Off-host copies and retention policy determine which larger failures a backup can cover. Until those workflows are implemented and tested, RURAL does not advertise disaster-recovery guarantees.