Restore & clone
How to restore a site or instance from a backup — into the same place or a new instance (which doubles as cloning/migrating) — and how the test-restore drill proves a backup before it's needed.
A backup is only as good as its restore. SpipCP restores at both levels — a site backup (files + database) and an instance snapshot (the whole container) — and a site can be restored into a new instance, which is also how a site is cloned or migrated.
Restoring overwrites the target. Every restore asks for confirmation and writes an audit row, and the confirmation is re-checked on the server.
Restore a site backup
On the site's Backups tab, each successful backup has a Restore button. The panel:
- Fetches the backup from offsite storage.
- Checks it and decrypts it (a corrupt or tampered backup fails here — it's never restored).
- Pushes the archive into the target instance and extracts it.
- Loads the database dump (if the backup has one).
- Runs the site's health check.
- Relaunches the site, re-applying everything the launch owns over the tree that just arrived.
By default the site restores into its own instance. To restore into a different instance (clone or migrate), choosing the target instance extracts the archive there instead, producing a copy of the site without touching the original.
Why a restore ends in a relaunch
A backup archives the site's files, and an old archive carries an old configuration. The health
check in step 5 only asks whether the site is serving — which it is, immediately, whatever shape
those files are in. Restoring a year-old backup would otherwise reinstate a year-old wp-config.php
and reintroduce every problem the panel has fixed since: an https redirect loop, a prompt for FTP
credentials on plugin installs, a missing scheduled-tasks plugin, file ownership that no longer
matches the docroot contract.
The relaunch re-applies all of it. Every step is safe to repeat — a restored wp-config.php keeps
its database settings, and an installed WordPress is never re-installed over. The restore is
recorded as successful before the relaunch begins, so the two are reported separately: a restore
that worked is never re-graded by what follows it.
Restore an instance snapshot
In the instance workspace, a snapshot has a Restore button that rolls the whole container back to the snapshot, and then relaunches every site on it that was live — for the reason above, at instance scale. A snapshot rollback replaces every docroot on the box at once, along with the web server configuration, the PHP pools and the service units, and no per-site record is made that anything happened to them; relaunching puts each one back on its current configuration.
A site that was stopped stays stopped. A recovery action never starts a site that somebody deliberately took down — which may well have been the reason for restoring the snapshot.
This is the fastest way to undo a bad change at the instance level. The pre-deploy snapshot is exactly this: a deploy that goes wrong is one click from the snapshot taken just before it.
Clone or migrate a site
Restoring a site backup into a new instance is the clone/migrate path:
- Create (or pick) the destination instance.
- On the source site's Backups tab, restore its latest backup and select the destination instance.
- The archive + database dump land in the new instance; point a domain at it when ready.
Cloning a WordPress site to a different domain? A restore copies the data as-is — including the
old URL stored in the database — so a clone served at a new hostname (e.g. a staging copy) still points at
the original. Use Change URL on the clone's Networking → Domains tab to rewrite it (a wp search-replace). Non-WordPress types store no URL, so a clone serves at any domain unchanged. See
Transfer an app → Change a site's URL.
The same mechanism powers a panel migration — see the migrate-panel runbook.
Move a live app (transfer) or a whole instance (migrate)
Restoring into a new instance makes a copy. To move a running site to another node or instance in one step — with an automatic traffic cutover and DNS re-point — use Transfer app on the site's Backups tab: see Transfer an app. To move a whole instance (the container/VM and every site in it), including across providers, see Instance migration.
The test-restore drill (restore, before it's needed)
There's no need to wait for a disaster to learn whether a backup restores. A daily drill restores each site's latest backup into a scratch instance, runs the health check, and reports. A failure — including a deliberately corrupted backup — raises an alert, the same way an outage does. Drill results show on the Backups page; a green drill is proof the backup is restorable.
Append-only & immutability
The security story behind backups — two separate credentials (an add-only backup lane and a delete-capable prune lane), how rest-server enforces append-only, where provider object-lock fits, and the one gap self-hosted object stores still have.
Transfer an app
Move a single site to another node or instance in one click — a backup → recreate → restore → re-point cutover that keeps the source serving until the destination is healthy.