Backups: the Only Real Undo

ROLLBACK saves you before COMMIT. Nothing saves you after — except a copy made earlier. That sentence is the whole page, and it may be the most adult sentence in this book: a backup, a full copy of the database written out on a schedule and kept somewhere else, is the only real undo a committed change ever gets.

The Marquee now has structure, constraints, transactions, and four promises with famous initials. This page is the floor under all of it. It is short, it is practical, and it ends with three questions you can ask in any team, anywhere, and be instantly useful.

What Can Still Go Wrong

Start with the honest list of disasters the previous three topics do not cover. The WHERE-less UPDATE from Chapter 5, except this time you looked, it seemed fine, and you typed COMMIT. The disk that simply dies one morning, taking the data files and their journal with it. Ransomware that encrypts the whole machine. A fire, a flood, a stolen laptop — the building itself.

Durability covers none of these. Durability, remember, means committed work survives a crash, and it keeps that promise with terrible faithfulness: it preserves your committed mistake exactly as reliably as your committed booking. It also lives on the same disk as everything it protects, so when the disk goes, the promise goes with it. Different disasters need a different tool.

The Shape of a Backup

The basic shape is a dump: on a schedule, a program reads the entire database and writes it out as one file of replayable SQL (every CREATE TABLE, and every row written back as a bulk data-load command), so that running the file against an empty database rebuilds the Marquee exactly as it was at that moment. For PostgreSQL, taking one looks like this:

pg_dump marquee > backup.sql

One line of demystification: pg_dump is a small command-line program, not part of the SQL language, and the > arrow means "put the output into this file". That is the entire trick — the fearsome-sounding backup is a text file you could open and read.

Two upgrades on the basic shape, named so you recognize them in the wild. Engines also offer continuous protection, where every change is archived as it happens so you can restore to any chosen minute; the term to know is point-in-time recovery, and knowing the name is enough for now. And every serious backup obeys the fire rule: the copy lives somewhere else — another machine, another building, another city. A copy on the same disk dies with the disk, and a copy in the same room burns with the room.

If Lora still kept her paper notebook, the right habit would be photographing every page once a week and mailing the photos to her sister across town. Frequency, distance, and the ability to actually re-read the photos: that is the entire discipline of backups, mapped onto paper. From here on, the real words.

An Untested Backup Is a Hope

Here is the part professionals learn the painful way: a backup you have never restored is not a backup, it is a hope. A restore is software plus assumptions: the file is complete, the versions match, the password is written down somewhere, someone remembers the steps. Every one of those assumptions loves to fail precisely during the fire.

The fix is a restore drill: on a calm day, take a recent backup and actually rebuild a working database from it, end to end. If it works, you have a backup. If it doesn't, you found out on a quiet Tuesday instead of during the disaster. "We had backups" is the saddest sentence in IT for exactly this reason — it is always spoken in the past tense, about files nobody ever tried to restore.

Managed Mercy

Now the good news. If the Marquee's database runs on a managed cloud service, which is where Chapter 9 is heading, scheduled backups are usually on by default: taken automatically, stored elsewhere, restorable from a dashboard. Small teams get, for free, a discipline that used to require a dedicated person. That is genuine mercy — and it still does not make the subject someone else's problem, because defaults have settings, and settings have surprises: how much history is kept, where the copies live, how long a restore takes.

So the reader's job, even when the doing is outsourced, is three questions: how often is it backed up? how far back can we go? when did we last test a restore? Anyone who asks those three in a meeting sounds like they have run databases for years. You now know why each one matters, which is better.