Restore from Backup
Restore a completed Devpilot backup to its original location or a new target, and track restore progress from the backup history panel.
Restore from Backup
A backup is only as useful as the restore that comes out of it. Devpilot lets you restore any completed backup to its original source, to a different server, or to a new database name — and it records every restore attempt so you always have an audit trail.
This page covers the standard restore flow from a saved backup file. For replaying a real-time stream to a specific moment in time, see Real-Time Backup.
Before You Restore
Restoring is a destructive operation against the target. If you restore into a live database with Overwrite enabled, the target's data will be replaced. Always double-check the target server and database name first.
You can only restore from a backup whose status is Completed. Runs that are still pending, in progress, failed, or cancelled aren't restorable.
Starting a Restore
Open Backup History
Go to Backups > History inside your workspace. This shows every backup run across all plans, with filters for plan, status, date range, and search.
Pick a Completed Backup
Click the backup you want to restore. The detail panel shows the plan it came from, the destination the file is stored in, its size, and any previous restore attempts under Restore History.
Click Restore
Open the Restore dialog from the detail panel. Devpilot will ask you where the backup should be restored.
Configure the Target
Fill in where the backup should land (see below). Devpilot checks that a target is provided before dispatching.
Run the Restore
When you confirm, Devpilot creates a restore record, marks it Pending, and begins the restore in the background. You can close the dialog and track progress from the Restore History section of the backup.
Target Configuration
When you restore, you tell Devpilot where the backup should land. You'll see:
- Target server — which server to restore into. Leave it empty and Devpilot restores back to the plan's original source.
- Target database name — override the database name on the target. Useful when you want to restore into
myapp_staginginstead of the originalmyapp. - Target path — for file-type backups, override the path where files will be extracted.
- Overwrite — off by default. When off, the restore fails if it detects an existing target with conflicting data. When on, existing objects on the target are replaced.
Restore Modes
Devpilot supports two common patterns.
Leave the target server and target database empty. The backup is written back to the same server and database it came from. Turn Overwrite on if you expect the target database to already exist — for example, after a bad deploy corrupted the live data.
Pick a different target server and, optionally, a fresh target database name. This is the safest pattern for testing: restore to a staging box, verify the data, then cut traffic over. Overwrite can usually stay off because the target is empty.
Restore Statuses
Every restore attempt is recorded as a restore history row on the backup. A restore moves through these states:
- Pending — queued and waiting to start.
- In Progress — actively running against the target.
- Completed — finished successfully. Check the target to confirm the data is in the shape you expect.
- Failed — hit an error. The restore record stores an error message you can open to see what went wrong.
Each row also records who triggered the restore and when it started and completed.
Where Restores Appear
Restores live alongside the backup they came from.
On the Backup Detail Page
Open any backup in Backups > History. The Restore History panel lists every restore attempt for that backup, newest first, with status, start time, completion time, and the user who triggered it.
On the Backup Plan
The plan detail view aggregates restores across all of its backups, so you can see how often the plan has been restored without drilling into individual runs.
Point-in-Time Restore via a CDC Stream
If your backup plan runs in real-time mode, you have a richer restore option: instead of restoring a single dump file, you replay the change stream up to a specific moment. This gives you "restore to 14:03 last Tuesday" precision.
The entry point is on the real-time plan's Stream tab, not on an individual backup history row. See Real-Time Backup > Point-in-Time Restore for the full flow.
What Gets Restored (and What Doesn't)
- Data inside the backup. Yes. For database backups this is the dump contents; for file backups it's the archived files.
- Destination credentials. No. You don't re-enter destination credentials during a restore — Devpilot uses the destination that owns the backup file to fetch it.
- Downstream systems. No. A restore only writes to the target you configure. If you have caches, search indexes, or read replicas fed off the original database, you'll need to rebuild those yourself after the restore completes.
- Existing data on the target. Depends on Overwrite. With Overwrite off, Devpilot refuses to clobber existing objects; with Overwrite on, they're replaced.
Reading a Restore Record
Each restore row stores the full context of the attempt so you can audit what ran where. You'll see the backup it was sourced from, the current status, the target the restore was pointed at (server, database name, path, and whether Overwrite was on), and when Devpilot began and finished the work — a Pending row has neither start nor finish time, an In Progress row has only a start time, and Completed or Failed rows have both. Failed rows also carry an error message, and every row records the user who kicked off the restore.
Common Scenarios
A migration went wrong in production. Open the most recent Completed backup from before the deploy, restore in place with Overwrite on, and verify the rollback against your application.
Pick the latest production backup, point the target at your staging server, and optionally change the target database name to a staging-specific one. Leave Overwrite off so Devpilot won't overwrite existing staging data by accident.
For real-time plans, use a point-in-time restore to a fresh database on a staging server, pick a moment just before the drop, then copy the recovered table back to production yourself.
Caveats
A restore that fails partway through can leave the target in a partially written state. If a restore moves to Failed, assume the target is inconsistent and either restore again with Overwrite on or wipe it before retrying.
- Only Completed backups are restorable.
- The destination that stores the backup file must still exist and be reachable — if it's been deleted or disabled, the restore will fail when Devpilot tries to download the file.
- Restores run in the background. Closing the UI or switching workspaces does not cancel a restore in progress.
Next Steps
Backup history
Browse every Devpilot backup run — filter by plan, status, or date; cancel in-progress jobs; download completed artifacts; and inspect file snapshots for file-type plans.
Real-Time Backup
Stream database changes to your destination in real time using Devpilot's change data capture (CDC) backup mode.