Backup Snapshot¶
Technical artifact — instantiates Checkpoint and Rollback
A durable, independently stored copy of data, files, or configuration, captured so the original can be reconstructed from it after loss or a bad change.
A Backup Snapshot is the artifact at the heart of the archetype: a copy of the payload — the files, records, model weights, or configuration — written to a store independent of the original, so that if the original is corrupted, deleted, or destroyed, the content can be rebuilt from the copy. Its defining trait is that it captures content, portably. Because the copy lives somewhere else — another disk, another region, tape in a vault — it survives events that take out the live system entirely, and it can be restored onto different hardware. That independence is exactly what separates it from an in-place revert: a Backup Snapshot is not a route back so much as the thing you keep so a route back is possible at all. The snapshot is only the stored copy; the act of restoring it, and the test that the restored system actually works, are separate concerns handled by other mechanisms.
Example¶
A photography studio runs a shared asset server holding a decade of client shoots — raw files, retouched masters, and the catalog database that ties them together. Every night an automated job writes an incremental copy to a second on-site drive and a nightly full to encrypted cloud storage; a monthly full is rotated to an offline drive kept off-premises. One morning the primary array's controller fails and takes the volume with it. Because the studio holds a Backup Snapshot — verified restorable by a quarterly test-restore of a sample shoot — the loss is a recovery, not a catastrophe. They provision a replacement array and rebuild from last night's full plus the day's incremental. The only unrecoverable work is whatever was shot and imported after the last incremental ran — hours, not years — because the incremental chain captured every change up to that point. The studio is back to editing by afternoon.
How it works¶
- Capture the content. Copy the data — full, incremental (only what changed since the last copy), or differential (everything changed since the last full) — on a schedule set by how much loss is tolerable.
- Store it independently. Keep copies on separate media and in separate locations, so no single failure can take out both the original and the backup.
- Verify restorability. Periodically read a copy back and confirm it is intact and reconstructable — a backup you have never restored is only a hope of a checkpoint.
- Rotate and retain. Age out old snapshots on a retention policy, keeping enough history to reach back past a corruption that went unnoticed for a while.
Tuning parameters¶
- Capture frequency — how often a snapshot is taken. More frequent shrinks the window of unrecoverable work but costs storage and I/O.
- Full vs. incremental mix — how often a fresh full baseline is taken versus cheaper deltas. Frequent fulls restore faster; long incremental chains save space but make restore slower and more fragile.
- Retention depth — how far back copies are kept. Deeper history survives slow-burning corruption but multiplies storage cost.
- Storage independence — how many copies, on what media, in how many locations. More independence survives bigger disasters; the discipline that governs this dial is the 3-2-1 rule.[n1]
- Immutability / encryption — whether copies are write-once and encrypted. Immutable copies survive ransomware and accidental deletion but cannot be pruned early.
When it helps, and when it misleads¶
Its strength is durability through independence: because the copy lives apart from the original, a Backup Snapshot survives the failure of the very system it protects, and can seed a rebuild onto entirely new hardware. That is the one guarantee an in-place mechanism cannot make.
Its classic failure mode is the untested backup — the copy exists but has never been read back, so no one actually knows whether it can be restored until the day they need it and discover it is truncated, encrypted with a lost key, or missing a dependency. This is "Schrödinger's backup": the state of a backup is unknown until you attempt a restore. The standard misuse is treating the existence of backups as a recovery capability, budgeting for capture but never for restore drills. The guarding discipline is to schedule periodic test-restores against the 3-2-1 rule[n1] and treat a backup that has never been restored as unverified.
How it implements the components¶
checkpoint— the snapshot is the saved recoverable state; capturing it is the archetype's checkpoint step made concrete as a stored artifact.known_good_state— the verification pass (test-restore, checksum) confirms the copy is intact and reconstructable, so the checkpoint is known-good rather than merely present.post_checkpoint_delta_capture— the incremental/differential chain records changes made after the last full baseline, so work done between fulls is preserved rather than silently lost.
It stores the copy but does not perform the reversal: the bounded in-place revert route — protected_change_scope and restoration_path — belongs to System Restore Point, and the post-restore restoration_test that confirms the live system is healthy is Database Snapshot Restore's job.
Related¶
- Instantiates: Checkpoint and Rollback — Backup Snapshot supplies the durable checkpoint every rollback ultimately restores from.
- Sibling mechanisms: System Restore Point · Database Snapshot Restore · Document Version Revert · Emergency Fallback Runbook · Deployment Rollback
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: A durable, independently stored copy of data, files, or configuration, captured so the original can be reconstructed from it after loss or a bad change, making its operative form a durable account of actual events, decisions, or transitions whose value depends on history or provenance.
Independent corroboration: The frozen evidence defines Backup Snapshot as 'A durable, independently stored copy of data, files, or configuration, captured so the original can be reconstructed from it after loss or a bad change', so its operative form is Record, Log & Register.
Nearest alternative: Representation, Specification & Plan — It preserves an actual recoverable state with provenance, rather than describing a prospective configuration.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Computing practice captures independently stored data and configuration snapshots so lost or corrupted systems can be reconstructed.
Related originating lineages:
- Library & Information Science — Digital preservation contributes durable copies, media diversity, and off-site custody.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
The nearest twin is System Restore Point, and the split is sharp: a Backup Snapshot copies the data content to an independent store so it can be restored anywhere, while a restore point captures only the machine's configuration and reverts it in place — a restore point deliberately does not protect your files, which is the one job a backup exists to do. Keep both; neither substitutes for the other.
[n1] The 3-2-1 rule — keep at least three copies of the data, on two different media types, with one copy off-site — is a widely taught backup guideline (popularized in US-CERT / CISA guidance) that operationalizes "storage independence." It is invoked here as the discipline for the independence dial, not as a study result. ↩a ↩b