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 you need it.
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 you clone or migrate a site.
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.
By default the site restores into its own instance. To restore into a different instance (clone or migrate), choose the target instance — the archive extracts there instead, giving you a copy of the site without touching the original.
Restore an instance snapshot
In the instance workspace, a snapshot has a Restore button that rolls the whole container back to 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 you're 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 you need it)
You don't have 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 your 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.