Keep it running
Rewinding your database — inside the window your plan keeps
A migration that deleted the wrong rows, a script that ran twice. Going back one version returns the code; this returns the data. How far back depends on your plan, and the two mechanisms underneath are genuinely different.
How far back
Plan | Granularity | How far |
|---|---|---|
Hobby | any hour | 7 days |
Pro | to the minute | 7 days |
Max | to the minute | 30 days |
What Hobby's hour actually is
An hourly pg_dump of your database on its own, kept for seven days. One file per database, deliberately: restoring your data should not mean rebuilding an instance that holds everybody else's.
It is a dump rather than a copy of the files because the shared instance is being written to continuously, and copying a live data directory produces a backup that restores into a corrupt cluster — which you discover during the restore, at the worst moment available.
What "to the minute" is
From Pro, the database has an instance of its own and keeps a continuous record of every change alongside a periodic base copy. That is what lets a restore land on a chosen minute rather than on whichever hour happened to be dumped. It needs a volume of its own to hold the log, which is why it starts at Pro rather than being switched on for everyone.
Before you rewind anything
A rewind replaces the data with what was there at the chosen time. Anything written after that point is gone — including the good rows written while you were working out what went wrong. If the damage is confined to a few rows, repairing them forward is usually better than rewinding an entire database over them.
Ask for it through your agent or through hello@erawan.cloud with the app and the time you want, in UTC or with the offset stated. A restore is not a self-service button on purpose: the destructive half is irreversible and the request is worth one exchange to get right.
The file database that is not covered
If your app keeps SQLite on its disk rather than using Postgres, the nightly offsite copy takes it — but it copies three files while your app writes between them, so what comes back can be internally inconsistent, and there is no rewinding to a minute. Schedule a VACUUM INTO before 04:00 to write one consistent file for the copy to take, or move to Postgres.