Restore an application
Put a backup back over a live application — what the panel does first, how to watch it, and how to undo it.
Restoring replaces a live application with a copy of itself from an earlier point. It is destructive by definition: anything written since that backup was taken is gone.
OSS Panel makes it reversible rather than safe. Before it overwrites anything it takes a safety copy of the application exactly as it is right now, so a restore you did not mean can be undone in one click.
Before you start
- Restores run from Complete backups only. A failed or unverified run cannot be used as a source.
- Restoring needs the server-level backup manage permission, not just the application's own backup permission.
- The application is unavailable for part of the run. On a 39 MB WordPress site that is seconds; on a large site it is minutes.
Steps
Find the backup. Either Backups → History, or the application's own Backups tab, which lists its most recent runs. Click Restore on the row you want.
Choose what to put back. A Files and database backup can be restored whole, or one half at a time:
| Option | Effect |
|---|---|
| Files and database | Everything in the backup. |
| Files only | Leaves the current database untouched. |
| Database only | Leaves the current files untouched. |
The header repeats when the backup was taken, what it contains and how big it is. Check those three before going further — restoring last month's copy because it was the row under your cursor is the mistake this screen is designed to catch.
Type the domain to confirm, then click Restore application. The button stays disabled until the text matches exactly; there is a copy icon next to it.
Watch the progress banner. It appears at the top of every Backups tab and survives a page reload — the run is on the server, not in your browser, so you can navigate away and come back.
The seven steps are: download the archive, verify it, take the safety backup, extract, restore the database, swap the files into place, restart the application. Everything before the database step is non-destructive — if the download is corrupt or the safety copy cannot be written, the run fails with the live application untouched.
After a restore
The banner turns green and offers two things.
- Undo this restore puts the safety copy back — the application as it was immediately before you pressed Restore.
- Dismiss clears the banner. Check the site first; the banner is the fastest route back if it is wrong.
The Restores tab keeps the full record: which application, what was put back, when it started, how long it took, and a Find safety copy button that jumps to the matching row in History.
Safety copies live with the application's other backups on the storage destination, tagged Safety copy. They do not count towards retention and are never pruned, so the way back from a restore does not disappear because seven newer backups happened.
If a restore fails
- Verification failed — the archive on the destination does not match what was recorded. Nothing was touched. Try an older backup.
- Stopped partway — the application may be in a half-restored state. Use Undo this restore to put the safety copy back, then investigate.
- The application's own Logs and the server's System Logs hold the detail.