Point-in-Time Recovery vs Snapshots: What You Lose

Someone runs a DELETE without a WHERE clause at 4:15pm. Your most recent backup is from 03:00. Everything between those two times is gone, and no amount of restoring will bring it back.

That gap has a name — recovery point objective, or RPO — and the point-in-time recovery vs snapshots decision is entirely about how large you are willing for it to be.

The two models

Snapshots capture the state of your data at a moment. They run on a schedule, usually nightly. Restoring one puts you back exactly where you were when it ran, and everything after it is lost.

Point-in-time recovery combines a base backup with a continuous stream of the database's write-ahead log. Because every change is recorded in order, you can replay to any moment covered by the retained log — including 4:14pm, one minute before the delete.

The difference is not incremental. It is the difference between "we lost a day" and "we lost a minute."

The number that decides it

Ask one question, honestly: if you lost everything written in the last twelve hours, what happens?

For a personal project, a documentation site, or an internal tool whose data is reproducible: not much. Nightly snapshots are genuinely the right answer, and paying for continuous archiving would be waste.

For anything with customers writing to it, the answer is usually some version of "we would have to email people and explain." Orders that no longer exist. Uploads that vanished. Messages that were sent and are now not there. The support cost alone typically exceeds a year of the difference in infrastructure spend.

The mistake is not choosing snapshots. The mistake is choosing snapshots by default, without ever asking what a twelve-hour hole would cost.

What snapshots are genuinely good at

They are not a lesser product. They cover failures PITR does not:

• Whole-disk loss. A snapshot on separate storage restores everything, including files the database does not own.
• Fast, coarse rollback. Reverting a botched migration on a staging environment is faster from a snapshot than replaying a log.
• Cost. Storing one copy a day is cheaper than storing every write.
• Simplicity. Fewer moving parts is a real operational property, especially for a small team.

The trap is treating them as sufficient for a database that takes continuous writes.

What PITR costs you

It is not free, and the costs are worth naming:

• Storage. You are keeping the base backup plus every write for the retention window.
• Complexity. Archiving has to work continuously. An archiver that has been silently failing for a week means your recoverable window ends a week ago — which is why monitoring the archive is as important as configuring it.
• Restore time. Replaying a log takes longer than restoring a snapshot. Your RPO improves; your RTO usually gets worse.

That last trade-off catches people out. PITR means you lose less data, not that you are back online faster.

The layered answer most teams actually need

In practice this is not a choice between two things. Production databases usually want three layers, because they fail in three different ways:

Snapshots, daily, retained a week or two. Cheap insurance against losing the machine. This is also what covers the non-database files sitting on the same volume.

Logical dumps, daily, kept off the host. A pg_dump is portable and consistent by construction. It restores onto a different major version, a different provider, or a laptop — which is what you want when the problem is the platform rather than the data.

Continuous archiving, when the data has customers in it. The layer that turns "we lost today" into "we lost a minute."

Each covers what the others do not. A snapshot does not help you move providers. A logical dump does not help you recover a file that was not in the database. Neither helps you undo a delete from four hours ago.

Where Dockup sits

Dockup gives you the two layers that cover the most common failures, and it is worth being precise about which those are.

Volume snapshots, on demand or on a schedule with a retention count:

dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api

Logical database backups, streamed straight to object storage and encrypted on the way:

dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json

Two properties of that second one matter for recovery. The backup never lands on the database host — it streams to storage as pg_dump produces it, so it does not share a fate with the disk it came from. And a dump that exits non-zero or produces zero bytes is deleted and recorded as failed rather than sitting in the list looking like a backup.

Continuous archiving is not something Dockup runs for you today. If your RPO genuinely needs to be minutes, that is worth knowing before you choose, and it is a reasonable thing to run yourself against a managed database while using the platform for everything else.

The exercise worth doing this week

Write down two numbers for your production database:

1. RPO — how much data you can lose. Measured in time.
2. RTO — how long you can be down. Also measured in time.

Then check what your current setup actually delivers, by restoring something. If the numbers you wrote down and the numbers your setup delivers are different, you have found a decision to make while nothing is on fire — which is the only good time to make it.

Frequently asked questions

What is the difference between RPO and RTO? RPO is how much data you lose — the gap between the last recoverable moment and the failure. RTO is how long recovery takes. Snapshots give you a large RPO and a short RTO; PITR reverses that.

Can I recover rows deleted an hour ago from a nightly snapshot? No. A snapshot restores the state at the moment it was taken. Anything written after it is not in the file. Recovering an arbitrary moment requires continuous archiving.

Is a volume snapshot the same as a database backup? No. A snapshot captures the disk, including whatever state the database was mid-write. A logical dump is internally consistent and portable to other versions and providers. Most production setups want both.

How long should I retain backups? Long enough to notice a problem. Corruption or a bad migration is often discovered days later, so a single day of retention frequently means the only backups you have already contain the damage.