How your backups are taken: base, delta and restore points

Taking a backup is easy; restoring one is hard. We designed the system around the second — because a backup is measured on the day it is restored, not the day it is taken.

The most misleading sentence in backups is "we take backups". The real question is not whether a backup was taken, but whether restoring actually works. Those are not the same thing, and the difference shows up on your worst day.

Two different things are backed up

An application accumulates state in two places: the database and the files. They have different natures, so they are captured with different methods.

For the database a consistent dump is taken — a coherent picture of one moment, not a half-copy caught in the middle of writes. For files, the relevant part of the disk is packaged.

Why one package instead of thousands of files

When file backups were first built, every file was stored as a separate object. It looked sensible: if few files change, few objects are written.

The problem surfaced on the first real restore. One box had accumulated more than seven thousand files, and the restore tried to download every one of them separately. It was slow, it was fragile, and a single failed download left the whole restore in an uncertain state.

Today the method is different: files are collected into a single compressed base package, and later backups add only the changes as a delta. Restoring that same box went from seven thousand downloads to two.

Restore points

The backup list is not a pile of files — it is a timeline. The console shows which moment you can return to: every full backup is a restore point, and the deltas between them let you land in between.

In practice this matters because "go back to last night" and "go back to eleven this morning" are different requests, and the second one is usually the one you actually need.

The rule we learned

A backup system can fail silently too. A job returning "success" does not mean a backup exists — the path may be wrong, the write may have been refused, the result may be an empty package.

So the backup chain reads its own output back: did the object really appear, is its size plausible, is its date today. If any of the three fails, the job is not counted as successful. Assuming that something works without measuring it is the most expensive assumption in backups.

Other posts