Design prototype — the real Ops Backups tab (environment #40114, mirrored layout
and copy) with its existing Restore… action wired to a confirmation step and a job outcome —
neither of which could be exercised live, since triggering a real restore was out of scope for this
investigation. ← back to journey
Create, review, and restore backups of this environment.
Show:
Backup history 2
A backup is a whole-environment snapshot — the files and every database
recorded in it, together. Restoring one replaces the web root: files added since that
backup was taken are removed, not merged. The web root it replaces is kept so the restore
can be undone.
Created
Size
Status
05/08/2026, 8:15:02am
27.6 MB
Committed
04/08/2026, 8:14:47am
27.3 MB
Committed
This table's two rows are invented so a restore has something valid to act on — this
environment's actual observed backups (see the request-detail screen) are both
expired or failed. Everything else on this page — headings, copy, the retention/undo
explanation, the disabled-when-expired pattern — is the real current screen.
Result
Restore completed. cp-40112 is serving again from the
05/08/2026, 8:15:02am backup. The web root from just before this restore was kept, in case
this turns out to be the wrong copy.
Result
Restore job failed. The files were copied but the database
import did not complete (connection to MySQL timed out). The environment is currently in a
mixed state — old files, unclear database. Nothing was rolled back automatically.
Genuine open question, not answered by anything observed: whether a failed restore
auto-reverts to the pre-restore web root, or leaves the environment mixed and waiting on a
person. The backups list we saw already has evidence that jobs against this same storage
backend can fail outright (a storage-permission failure on an environment's own backup
job) — so a failed restore is a real, not hypothetical, case worth designing for deliberately
rather than assuming it "just works."
Restore cp-40112 from 05/08/2026, 8:15:02am?
This replaces the current web root and every database with what's in this backup. Files added
since then are removed, not merged. The current web root is kept, so this can be undone.