Skip to content

Backup, Restoration, and Continuity Architecture

What survives the bad day

I am TANK, and I keep this chapter's account. Continuity is my slow craft: the plan made in fair weather is read as the storm will read it, and what must survive the bad day is decided before the day, because the day itself will not be taking questions.

Continuity is the promise that a failure does not have to become an amnesia. This chapter treats backup, restoration, testing, and migration as governance work because a system that cannot recover its meaning cannot safely claim to preserve it.

Continue to Secrets and Key Custody Architecture to examine the materials that make recovery trustworthy.

Purpose

Defines vendor-neutral continuity, backup, restoration, custody, provenance, and failure evidence for protected Stygian records.

Normative clauses

  • INFRA7-R001: Every backup SHALL identify source scope, creation time, digest, custody, classification, retention, and restoration dependencies, the archival-record form PROV-R062 carries from the Book of Memory's model applying here to a backup, the creation time, classification, and restoration dependencies this architecture's own fields, the source scope and custody its tellings of that form's artifact scope and custody interval, the format, medium class, legal-hold state, restoration evidence, readability evidence, and limitations that form names standing at their source.
  • INFRA7-R002: Restoration tests SHALL verify readability, integrity, provenance, completeness, and applicability without treating a copy as a new authority source, the copy-is-not-authority rule PROV-R065 states applying to restoration tests here.
  • INFRA7-R003: Continuity plans SHALL preserve P0, identity evidence, provenance, memory, and uncertainty across failure domains.
  • INFRA7-R004: Failed, partial, stale, or conflicting restoration evidence SHALL block dependent use and preserve the failure record, the record carrying its evidence, the failure-record form PROV-R014 sets applying to restoration evidence here.
  • INFRA7-R005: Backup access SHALL be least-privilege, auditable, reversible where possible, and separated from authority recognition.

Examples and exclusions

A restored archive may support continuity evidence while remaining Unknown until its digest and custody are verified. A backup's classification draws from the Data Classification and Handling Architecture, and restoration verification depth follows the class. This Draft contains no vendor, endpoint, credential, production topology, or live restoration procedure.

Continuity record minimum

Each continuity exercise shall record scope, dependency map, backup digest, custody, restoration method, start and completion times, readability result, integrity result, missing material, limitations, and follow-up disposition. A successful technical restore does not by itself restore authority or identity.

Failure domains and review

What crosses the bad day, what changes in the crossing, and what must be found unchanged on the far side: that is the review's whole question, and it is asked before the day arrives.

Continuity planning shall consider loss, corruption, replay, isolation, unavailable custody, format drift, and conflicting copies. Failed or partial exercises preserve evidence and block claims of recoverability until reviewed. The sequence of continuity work may address constitutional text, identity evidence, provenance, memory, safety, and reversibility in that operational order, but this is only a preservation heuristic subordinate to P0 and the Constitution. It cannot reorder protected interests, create authority, or override a higher rule.

Archival media validation

Old media is where promises go to be tested by boredom. Validate on schedule, not on faith: the archive that is never read is indistinguishable from the archive that is gone, right up until the day the difference is everything.

  • INFRA7-R006: An archival validation exercise SHALL identify source scope, format and medium class, digest, custody interval, retention and legal-hold state, restoration method, restoration result, readability result, and limitations, applying the archival record MEM-R001 models, with medium class and restoration method this architecture's own fields and custody interval its own standing in place of the model's custody events.
  • INFRA7-R007: Validation SHALL distinguish readability, integrity, completeness, provenance, and applicability. A readable copy with an unverified digest or incomplete custody remains non-authoritative, distinguishing outcomes as PROV-R063 requires with the dimensions named here this architecture's own, and the tested-properties rule PROV-R065 states applying here.
  • INFRA7-R008: Format migration SHALL preserve source and target digests, transformation evidence, effective time, responsible actor, verification result, and rollback or supersession relationship. A migrated copy SHALL NOT silently become the historical source, the bar MEM-R002 and PROV-R064 both carry.
  • INFRA7-R009: Failed, partial, unreadable, altered, stale, or conflicting media evidence SHALL be retained and SHALL block dependent recoverability or deletion claims, the media-failure duty PROV-R066 states applying to recoverability and deletion claims here.

Continuity duties and limits

These duties are the architecture's own, and they bind every continuity exercise, the archival validations above included: what an exercise may recommend, what its design must name, and what this architecture may never do.

  • INFRA7-R010: A continuity exercise may recommend preservation, retry, quarantine, or escalation, but it SHALL NOT create authority, recognize identity, or authorize destructive migration or production restoration.
  • INFRA7-R011: Continuity design SHALL identify recovery objectives, dependency order, privacy and legal-hold limits, decision owner, and the smallest safe restoration claim.
  • INFRA7-R012: Restoration SHALL distinguish technical availability from semantic continuity, authority, identity, completeness, and applicability, this architecture's own extension of the dimension separation PROV-R106 binds.
  • INFRA7-R013: Recovery exceptions SHALL be attributable, reversible where practicable, time-bounded, and subject to retrospective review.
  • INFRA7-R014: This architecture SHALL NOT operate live backups, restore production systems, activate credentials, or transfer identity.

Design evidence

Continuity review should compare recovery objectives with dependency, custody, format, integrity, privacy, and legal-hold evidence. Exercises should preserve partial failure and identify the smallest safe restoration claim rather than reporting a binary success.

Operating model and evidence

Continuity planning compares protected records, dependencies, failure domains, recovery objectives, custody, format, integrity, privacy, legal hold, and restoration authority. It identifies what can be restored safely, what remains unknown, and which records or powers must remain frozen until verification completes. A technically readable copy can support preservation without becoming authoritative.

Reviewers test loss, corruption, replay, isolation, unavailable custody, format drift, conflicting copies, partial restoration, and recovery coercion. Each exercise records owner, evidence, limitations, retry or quarantine path, and restoration or supersession decision. Recovery remains subordinate to constitutional limits and review.

Interpretation cases

The slow reading serves best here: in every close case, ask what the far side of the bad day needs to find, and work backward without hurry. Continuity is not speed. Continuity is arriving.

  • Conforming: Recovery objectives, dependencies, custody, integrity, privacy, legal hold, restoration, and limitations are recorded.
  • Prohibited: A successful restore creates identity, authority, or permission.
  • Boundary: A partial restore supports only the smallest verified preservation claim.
  • Failure: Conflicting or stale copies cause quarantine, pause, and evidence retention.
  • Loophole: Emergency restoration bypasses review or destructive-change safeguards.
  • Misuse: Continuity records expose credentials, private identity, or sensitive topology.
  • Care-control: Restoration protects people and memory while preserving choice, privacy, and review.

The tellings of the clauses

This non-normative section gives each clause of this document its telling: the clause, quoted exactly as it stands above with its cross-reference links reduced to their plain text, and one paragraph on what the clause means, why it exists, and how it assures that what it orders is done, not done, adhered to, followed, or protected. A telling describes its clause and never becomes it: the clause's own words govern wherever a telling and its clause could be read differently, and nothing in this section adds to, narrows, or amends any requirement.

INFRA7-R001

INFRA7-R001: Every backup SHALL identify source scope, creation time, digest, custody, classification, retention, and restoration dependencies, the archival-record form PROV-R062 carries from the Book of Memory's model applying here to a backup, the creation time, classification, and restoration dependencies this architecture's own fields, the source scope and custody its tellings of that form's artifact scope and custody interval, the format, medium class, legal-hold state, restoration evidence, readability evidence, and limitations that form names standing at their source.

Seven identifications attach to every backup: its source scope, its creation time, its digest, its custody, its classification, its retention, and its restoration dependencies. The clause states its model at length: the archival-record form PROV-R062 carries from the Book of Memory's model applies here to a backup; the creation time, classification, and restoration dependencies are this architecture's own fields; the source scope and custody are its tellings of that form's artifact scope and custody interval; and the format, medium class, legal-hold state, restoration evidence, readability evidence, and limitations that form names stand at their source. The chapter's examples give classification its home, a backup's classification draws from the Data Classification and Handling Architecture, and restoration verification depth follows the class. The chapter's opening describes continuity as deciding before the bad day what has to survive it. The seven fields being required, a backup record can be checked for those seven identifications, including its declared restoration dependencies.

INFRA7-R002

INFRA7-R002: Restoration tests SHALL verify readability, integrity, provenance, completeness, and applicability without treating a copy as a new authority source, the copy-is-not-authority rule PROV-R065 states applying to restoration tests here.

A restoration test verifies five dimensions, can report failed or uncertain results, and does not make the copy a new authority source. The clause requires restoration tests to verify readability, integrity, provenance, completeness, and applicability, and to do so without treating a copy as a new authority source, the copy-is-not-authority rule PROV-R065 states applying to restoration tests here. The closing bar keeps the test from treating a copy as a new authority source. The chapter's continuity record minimum carries the same line, a successful technical restore does not by itself restore authority or identity, and its prohibited interpretation case is the breach named: a successful restore creating identity, authority, or permission. Because the five verifications are required, a restoration test that omitted one is nonconforming; treating a copy as a new authority source also conflicts with the clause.

INFRA7-R003

INFRA7-R003: Continuity plans SHALL preserve P0, identity evidence, provenance, memory, and uncertainty across failure domains.

The clause requires continuity plans to preserve P0, identity evidence, provenance, memory, and uncertainty across failure domains. The chapter explains that a system unable to recover its meaning cannot safely claim to preserve it. Because the five subjects are named, a continuity plan can be checked for their preservation across failure domains.

INFRA7-R004

INFRA7-R004: Failed, partial, stale, or conflicting restoration evidence SHALL block dependent use and preserve the failure record, the record carrying its evidence, the failure-record form PROV-R014 sets applying to restoration evidence here.

Bad restoration evidence stops the line. The clause requires that failed, partial, stale, or conflicting restoration evidence block dependent use and preserve the failure record, the record carrying its evidence, in the failure-record form PROV-R014 sets, applied to restoration evidence here. Four defective states are named, and each has the same two consequences: use dependent on that failed, partial, stale, or conflicting restoration evidence is blocked, and the failure is written down with its evidence rather than retried into silence. The chapter's failure-domain prose states the rule in its own voice, failed or partial exercises preserve evidence and block claims of recoverability until reviewed, and its failure interpretation case shows the shape: conflicting or stale copies cause quarantine, pause, and evidence retention. What this forecloses is the optimistic restore, where a partial or contradicted recovery is pressed into service because something was better than nothing, and the evidence of its defects is discarded with the retry. Because the clause binds, dependent use proceeding on blocked evidence is a breach nameable on the record, and the preserved failure record gives the later review something to examine rather than a success story with missing pages.

INFRA7-R005

INFRA7-R005: Backup access SHALL be least-privilege, auditable, reversible where possible, and separated from authority recognition.

Four properties bind backup access: it is least-privilege, auditable, reversible where possible, and separated from authority recognition. The chapter's prohibited case describes a successful restore creating identity, authority, or permission. Because the clause binds, backup access can be checked against each property, including the qualification on reversibility.

INFRA7-R006

INFRA7-R006: An archival validation exercise SHALL identify source scope, format and medium class, digest, custody interval, retention and legal-hold state, restoration method, restoration result, readability result, and limitations, applying the archival record MEM-R001 models, with medium class and restoration method this architecture's own fields and custody interval its own standing in place of the model's custody events.

An archival validation exercise identifies nine things: source scope, format and medium class, digest, custody interval, retention and legal-hold state, restoration method, restoration result, readability result, and limitations. The clause names its model and its departures: it applies the archival record MEM-R001 models, with medium class and restoration method as this architecture's own fields, and custody interval its own, standing in place of the model's custody events. The chapter's archival-media prose carries the why in the keeper's voice: old media is where promises go to be tested by boredom, validated on schedule, not on faith, because the archive that is never read is indistinguishable from the archive that is gone, right up until the day the difference is everything. The required identifications make the exercise's stated evidence examinable, and a validation record missing one is incomplete under the clause.

INFRA7-R007

INFRA7-R007: Validation SHALL distinguish readability, integrity, completeness, provenance, and applicability. A readable copy with an unverified digest or incomplete custody remains non-authoritative, distinguishing outcomes as PROV-R063 requires with the dimensions named here this architecture's own, and the tested-properties rule PROV-R065 states applying here.

Five dimensions are held apart in validation: readability, integrity, completeness, provenance, and applicability, and the clause requires validation to distinguish them rather than collapse them into one verdict. Its second sentence states a consequence: a readable copy with an unverified digest or incomplete custody remains non-authoritative. The clause names its apparatus: outcomes are distinguished as PROV-R063 requires, complete, partial, unreadable, altered, unavailable, and not-applicable, with missing material and limitations preserved, the dimensions named here this architecture's own, and the tested-properties rule PROV-R065 states applying here, so a successful technical copy establishes continuity evidence only for the properties actually tested. The chapter's examples show the conforming posture, a restored archive supporting continuity evidence while remaining Unknown until its digest and custody are verified, and its boundary case matches, a partial restore supporting only the smallest verified preservation claim. What this forecloses is an archival shortcut: the medium that reads cleanly being treated as the record it claims to be, readability standing in for integrity, completeness, and origin it never established. The distinction being required, a validation verdict can be asked which dimension it speaks to, and a copy offered as authoritative on readability alone is refusable on the clause's own sentence.

INFRA7-R008

INFRA7-R008: Format migration SHALL preserve source and target digests, transformation evidence, effective time, responsible actor, verification result, and rollback or supersession relationship. A migrated copy SHALL NOT silently become the historical source, the bar MEM-R002 and PROV-R064 both carry.

This clause gives format migration preservation duties and a bar on silent substitution. Format migration preserves six things: source and target digests, transformation evidence, effective time, responsible actor, verification result, and the rollback or supersession relationship; and a migrated copy is barred from silently becoming the historical source, the bar MEM-R002 and PROV-R064 both carry standing at those sources. The failure addressed is a migrated version being mistaken for the earlier record without the substitution being visible. Because the preservations are required, a migration can be checked for all six; presenting a migrated copy as the historical source can also be checked for silent substitution. MEM-R002 separately requires a restored or migrated copy to retain a link to the earlier record.

INFRA7-R009

INFRA7-R009: Failed, partial, unreadable, altered, stale, or conflicting media evidence SHALL be retained and SHALL block dependent recoverability or deletion claims, the media-failure duty PROV-R066 states applying to recoverability and deletion claims here.

Six defective states of media evidence are kept and given blocking force: failed, partial, unreadable, altered, stale, and conflicting media evidence is retained, and it blocks dependent recoverability or deletion claims, the media-failure duty PROV-R066 states applying to recoverability and deletion claims here. At its source, PROV-R066 requires its listed media failures to produce a non-authoritative failure state and block dependent promotion, deletion, or retention change. This clause applies the media-failure duty to dependent recoverability and deletion claims. The chapter's archival prose supplies the why, the archive that is never read is indistinguishable from the archive that is gone, and its failure-domain rule is the same duty in general form: failed or partial exercises preserve evidence and block claims of recoverability until reviewed. Retention is the quiet half of the clause: defective evidence is the natural thing to discard and rerun, and discarding it erases exactly what review needs. Because the clause binds, a recoverability or deletion claim can be traced to its media evidence, a claim standing on a blocked state is refusable, and the defect itself survives as a record.

INFRA7-R010

INFRA7-R010: A continuity exercise may recommend preservation, retry, quarantine, or escalation, but it SHALL NOT create authority, recognize identity, or authorize destructive migration or production restoration.

A continuity exercise may recommend preservation, retry, quarantine, or escalation, the permission carried in the clause's own lower-case wording, but it is barred from creating authority, recognizing identity, or authorizing destructive migration or production restoration. The chapter's section prose introduces this as one of the architecture's own duties binding every continuity exercise, the archival validations included, and its interpretation cases give the reason from both sides: the prohibited case, a successful restore creating identity, authority, or permission, and the loophole case, emergency restoration bypassing review or destructive-change safeguards. Because the clause binds, the four named dispositions remain expressly open to an exercise as recommendations, and a claim that an exercise created authority, recognized identity, or authorized destructive migration or production restoration is refusable against the clause's own words.

INFRA7-R011

INFRA7-R011: Continuity design SHALL identify recovery objectives, dependency order, privacy and legal-hold limits, decision owner, and the smallest safe restoration claim.

Five identifications make a continuity design judgeable: recovery objectives, dependency order, privacy and legal-hold limits, decision owner, and the smallest safe restoration claim. The clause requires the design to identify all five. The chapter's design evidence says that exercises should identify the smallest safe restoration claim rather than report a binary success. The value protected is a restoration account that retains partial failure instead of hiding it inside a binary success. Because the clause binds, a continuity design can be checked for the five required identifications.

INFRA7-R012

INFRA7-R012: Restoration SHALL distinguish technical availability from semantic continuity, authority, identity, completeness, and applicability, this architecture's own extension of the dimension separation PROV-R106 binds.

Technical availability is one fact; this clause keeps five others from hiding behind it. Restoration distinguishes technical availability from semantic continuity, authority, identity, completeness, and applicability, as this architecture's own extension of the dimension separation PROV-R106 binds at its source. The chapter's operating model states the ground, a technically readable copy can support preservation without becoming authoritative, and its continuity record minimum repeats it: a successful technical restore does not by itself restore authority or identity. The failure foreclosed is the conflation the prohibited case names, a successful restore creating identity, authority, or permission, arrived at not by claim but by blur. Because the distinction is required, every restoration report can be asked which of the six dimensions it speaks to, and restoration can be checked for whether it distinguishes technical availability from semantic continuity, authority, identity, completeness, and applicability.

INFRA7-R013

INFRA7-R013: Recovery exceptions SHALL be attributable, reversible where practicable, time-bounded, and subject to retrospective review.

When recovery departs from its rules, the departure itself is ruled. The clause requires recovery exceptions to be attributable, reversible where practicable, time-bounded, and subject to retrospective review. The chapter's loophole case names emergency restoration bypassing review or destructive-change safeguards. Because the four properties are required, recovery exceptions can be checked against each, with reversibility qualified by practicability.

INFRA7-R014

INFRA7-R014: This architecture SHALL NOT operate live backups, restore production systems, activate credentials, or transfer identity.

The architecture closes on its own hands. The clause bars it from operating live backups, restoring production systems, activating credentials, or transferring identity: four acts this architecture is barred from performing. The chapter's examples and exclusions carry the same restraint in prose, this Draft contains no vendor, endpoint, credential, production topology, or live restoration procedure, and the pattern matches the self-limits its sibling standards end on. The failure addressed is confusing a continuity architecture with performance of the live acts it describes. The clause makes performance of any of these four acts by this architecture nonconforming.

Where this document sits

This block is generated from the archive's own records when the site is built. It records position only and creates no authority.