# How long does a restore take?

> Measured SupaHost restore times, how long a project is offline during a restore, what makes restores slower, and what happens to other projects on the instance.

Source: https://supahost.app/kb/how-long-restore-takes · Updated 2026-11-11

Restoring a project on SupaHost usually takes minutes, and the project itself is offline for only part of that time. In a restore drill on a Pro instance (November 2026, same data every run):

| Database size | Total time | Project offline |
|---|---|---|
| 0.8 GB | about 4 minutes | about 55 seconds |
| 4.1 GB | about 12 minutes | about 4.5 minutes |

Other projects on the same instance stay online throughout.

## What happens during a restore

You start a restore from *Dashboard → your project → **Backups***: **Restore <project>** on a listed backup, or **Restore to this point** with a date and time (Pro and Business). You type the project name to confirm. Then:

1. **Rebuild.** SupaHost takes the base backup before your restore point and replays the database's change log (WAL) up to that point. This happens in a separate, temporary Postgres with no network. Your project is still online and serving traffic.
2. **Extract.** It dumps just your project's database from that temporary copy.
3. **Swap.** Your project's Auth, Data API and Storage are stopped. The live database is renamed out of the way and kept as a fallback.
4. **Load.** The dump is loaded as the project's database, and the services start again.

Only steps 3 and 4 take the project offline. That's why a 4.1 GB database is offline for minutes, not for the whole restore.

## What makes it slower

- **Database size.** The load in step 4 takes longer for bigger databases, especially ones with lots of indexes, since they're rebuilt as the data loads.
- **The whole instance's size.** Base backups cover the instance's whole Postgres server, so step 1 unpacks every project's data, not just the one you're restoring.
- **How far the restore point is from the last base backup.** Base backups are taken daily. A point late in the day means more change log to replay than one just after a backup.
- **Write volume.** A busy instance produces more change log to replay.
- **Instance size.** Larger plans have more CPU and memory for the rebuild and load.

## On SupaHost

- You get an email when the restore finishes or fails.
- If anything fails, SupaHost puts the original database back, so a failed restore leaves you where you started.
- The database from before the restore is kept for 3 days, then dropped.
- A restore job times out after 6 hours.
- Storage files aren't rolled back. See [A restore didn't bring back Storage files](/kb/restore-storage-files).
- Cron jobs keep running against the restored data. Pause jobs with side effects first: see [Stopping cron jobs on a restored project or branch](/kb/stop-cron-after-restore).
- Only the instance owner can start a restore.

## Tips for a smoother restore

- Practise once on a test project with similar data, so you know the timing before you need it.
- Plan the offline window like a short deploy: show a maintenance message in your app, or pause background workers that write to the database.
- Take a fresh **Create pg_dump** export first if you want your own copy of the current state as well.

## Related

- [Restoring a project](/docs/platform/restore)
- [Point-in-time recovery](/docs/platform/point-in-time-recovery)
- [Backups](/docs/platform/backups)