> There are no backups. There is a week of history and a restore that takes seconds. # Backups and restore **There is no backup job, and that is the point.** Nothing is dumped at 3am and copied somewhere; the storage keeps every version of every page for the last **seven days**. Restoring is a pointer moved, not data shipped — it takes seconds on a database of any size. ## Restore to a moment On your **production** branch, choose a moment in the last seven days and press **Restore**. The branch is rewound to how it looked then. Anything written after that moment is no longer on it. **What was there is kept.** Before rewinding, the current state is saved as a new branch called `before-restore-`. So a restore aimed at the wrong moment is not a catastrophe — the thing you were trying to rescue is on that branch, and you can restore again or copy rows out of it. That branch has **no compute** to begin with, which keeps a backup nobody is reading from costing anything. Open it and press **Start compute** to connect to it; delete it when you are sure you no longer need it. ## What this covers, and what it does not | | | |---|---| | A migration that did the wrong thing | Restore to just before it ran | | `delete from …` without a `where` | Restore to a minute before | | A bad deploy that wrote nonsense for an hour | Restore to before the deploy | | A mistake found **eight days later** | Outside the window — nothing to restore from | | Someone deleting the project | 30-day window; ask us | | Someone deleting the *database* | Immediate and final. There is no undo | Seven days is the window on our current plan. If you need thirty, ask — it is a setting, and it costs more, because history is storage you are holding. ## Taking your own copy Nothing stops you, and for anything you must keep beyond a week you should: ```bash pg_dump "$DIRECT_URL" -Fc -f backup.dump ``` Use the **direct** connection string. That file is yours, restores into any Postgres anywhere, and is the only copy that survives us entirely — which is the honest recommendation for data whose loss would end an argument about whose fault it was. ## Branching as a rehearsal The other use of the same machinery: before a migration, branch production, run the migration on the branch, look at the result. It costs the difference and takes a second, and it is a better answer than a backup because you find out before rather than after. See [branches](/docs/data-api/browsing).