Restore a site from a backup
A backup is only as good as your last successful restore. Here’s how restoring works on OrbixPanel and how to rehearse it so the real thing is calm, not panic.
How restore works
OrbixPanel restores a snapshot (a point-in-time backup) back onto the server:
- Pick a snapshot — a specific date, or latest.
- Restore it to a target location.
- For databases, re-import the dump from the snapshot.
Each scheduled backup is its own snapshot, so you can roll back to a known-good point in time — e.g. “yesterday, before the bad plugin update.”
Restore the two halves
- Files — restore the site’s files from the snapshot back into its web root.
- Database — re-import the database dump from the snapshot → import a database.
Then reconnect the app (check its DB credentials) and reload the site.
Practice restore (do this before you need it)
Once a month, restore the latest snapshot to a scratch location and confirm:
- The files are all there.
- The database imports cleanly and the data is current.
- A test copy of the site actually loads.
This catches the nasty surprises — a missing database in the backup, a wrong path, a bad credential — while it’s a drill, not an outage.
Common restore scenarios
| Situation | Restore |
|---|---|
| Bad deploy / broken update | the last snapshot before the change |
| Hacked site | a clean snapshot from before the compromise, then patch the hole |
| Accidental deletion | latest snapshot, or the file from a recent one |
| Whole server lost | rebuild on a new box, then restore — change servers |
Keep the restic repository password safe — you need it to restore. No password, no restore.
Running OrbixPanel? Point-in-time snapshot restore is built in. OrbixPanel.com → — the free, self-hosted, AI-powered hosting control panel.