A restore replaces the production site with the contents of a snapshot. Before it touches anything, the panel takes a new backup of the site and checks it: if that backup fails its restore test, the restore stops and the site stays as it was.

DangerA restore replaces the current data

Whatever changed on the site after the snapshot disappears from the site. It survives only in the safety snapshot taken at the start of the restore.

Restore from the panel

1. Open the site and choose the Backups tab.
2. Pick a snapshot whose test passed and press Restore on its row.
3. In What to restore choose:
   • Everything (files and database);
   • Files only;
   • Database only.
4. Press Continue, type the site's domain to confirm, and press Restore.
5. Follow the task Restore started to its end.

The safety snapshot appears in the list of backups: if you need to go back, restore that one.

What changes on the site

• Files: the site folder is swapped for the snapshot's in one step, with no moment where the site has no files. Then the site's PHP restarts and nginx reloads its configuration. If the site does not come back, the panel puts the previous folder back.
• Databases: each database the backup holds is emptied and recreated from its dump. Tables created after the snapshot do not stay. If one import fails, that database and every one restored before it go back to what they were.
• At the end the site's page cache is emptied. With Database only, the object cache is flushed too, so the site does not serve stale data.

Which databases

From the panel and with cgctl, Everything and Database only restore every database the backup holds that the site still has.

• A database the backup holds and the site no longer has is skipped, and the task names it. To restore it, create it again with the same name in the Database tab, then restore.
• A database created after the backup is not in it, and stays as it is.
• A site with no database cannot take a Database only restore.

To restore only some databases, use the API: POST /api/backups/<backup-id>/restore with {"confirm": "<domain>", "mode": "database", "databases": ["shop_data"]}. Each name must be in the backup and still a database of the site; with "mode": "files" no database can be named.

From the command line

bash

cgctl --wait backup restore <backup-id> <domain> files

<backup-id> is the id field of a backup in the list GET /api/sites/<site-id>/backups; <domain> is the site's domain, as confirmation. The last word is full (the value when you leave it out), files or database.

Next step

To see why a backup that counts can always be restored, read Backups and restore tests.