Restores
Restoring a site from a backup, from either copy.
Starting a restore
From the site's Backups page or the fleet-wide list, a backup that is restorable offers an administrator Restore database and Restore full. A restore is confirmed before it starts; it changes the live site.
What happens
- From the site's copy, the worker puts the database back and then the files, one piece at a time. A failure part-way rolls back rather than leaving half a database; the live site is unavailable only for the moment the new database is switched in.
- From the external copy, the platform first brings the backup back onto the site: the worker downloads it from object storage piece by piece, through links the platform hands it that are valid for a limited time, and only a site holding a complete, verified copy is then asked to restore. A link that expires mid-download is renewed; the site keeps every piece it already has.
The worker refuses a restore from a copy on the site whose files are not all there, rather than restoring whatever happens to be in the directory; the platform then restores from the external copy when there is a whole one, and says so if there is not.
A restore is the only thing that runs on the site while it runs: no backup, update round or worker update starts on that site until it has finished.
What a restore keeps
Since worker 2.3.0 a restore keeps the site's connection to the platform and the work in flight, rather than rolling them back to the backup's day.
The Restores page
Each site's Restores page lists its restores with their phase — pending, fetching, preparing, processing, completed, failed, cancelled — the copy each read from, and the outcome.