The Copy That Saves You

Constraints refuse bad cards. Transactions forbid half-finished changes. Neither helps when the building burns down — or, statistically more likely, when a disk dies of old age, a laptop grows legs, or someone with the pen deletes the wrong ten thousand rows inside a perfectly valid transaction. For the disasters that defeat prevention, the vault keeps one more thing: a copy.

Backups

A backup is a complete copy of the database — every drawer, every card, the schema itself — taken at a moment in time and stored somewhere else. Each part of that sentence is load-bearing:

• Complete: not the important tables. All of it. Disasters don't consult your priorities.
• At a moment in time: a backup is a photograph — "the library, exactly as it stood at 02:00 on August 24." Photographs age, which is why backups run on a schedule — every night, commonly — so the freshest photo is never older than one day. Automated, because a backup that relies on someone remembering is the human error it's meant to survive.
• Somewhere else: a photocopy stored on top of the original burns in the same fire. Different disk at minimum; different building — across town, another city — for anything that matters.

This is why "the database server is down" and "the facts are gone" are different sentences. Machines are replaceable within hours. Data that exists in one copy is one bad Tuesday from not existing.

Restore: the half everyone skips

A backup you've never restored from is a hope, not a plan. Restore is the reverse operation — take the photograph, rebuild the library from it — and it's where backup plans actually fail: the nightly file that turns out corrupt, the copy nobody has the password to, the restore that needs a program last seen in 2019. Real libraries run the drill: restore a backup somewhere harmless and check the books are in it. If you've never watched your backup become a working database, you don't know whether you have one. You know you have a file.

One honest limitation, so it never ambushes you: restoring yesterday's photo recovers yesterday. Cards filed after 02:00 are lost — the gap is the price of the photograph model, and losing one morning versus losing everything is the whole negotiation. (Serious systems shrink the gap by also keeping a running journal of changes between photos — a story for a later course; the photo comes first.)

The mindset

Here's the shift this lesson is really after. Prevention — constraints, transactions, care — treats disaster as avoidable. Backups treat it as scheduled but undated. The disk will die; the wrong DELETE will run someday, with a valid WHERE and the wrong intent behind it. A library that plans to be rescued isn't pessimistic. It's the only kind that gets to be old.

So the vault now refuses bad cards, forbids half-changes, and can rise from ashes. One question remains, and it's the human one: who is allowed in the vault at all — and which keys do they carry? Next lesson: permissions.