Get wrenfield.example working again
RESTORE-4471 · opened today · Production (cp-40112)
Status
- ✓Sent to our teamCaching plugin, this morning ~9am AEST. Self-service backup taken first.Today, 9:42am
- ✓Picked up by SamReviewing your environment's recent backups and server logs.Today, 9:58am
- ●Restoring to the copy from before the updateYour current files are kept, so this can be undone if it's not the right copy.Started 10:04am
- Confirm it's workingWe'll check the site is serving again and let you know.
Status
- ✓Sent to our teamCaching plugin, this morning ~9am AEST.Today, 9:42am
- ✓Picked up by SamChecked this environment's backup history.Today, 9:58am
- !No usable backup on fileBoth recorded backups for this environment have passed retention and their stored copies were removed. We can't restore from either. We can rebuild manually from what's on the live server now, or you can tell us about another copy you may have — but we wanted you to know before spending time on this.Today, 10:11am
- Waiting on youReply on this request to tell us how you'd like to proceed.
Gap this surfaces: in the real ops portal, both of this environment's backups are already
shown as "Expired" with their Restore action disabled — this is a live, reachable dead end
today, not a hypothetical. Nothing in the current client portal would tell the customer that
before or after they ask for a restore.
Assumed, not confirmed: the specific stage labels and the idea of the operator replying
through this same request thread. The underlying "operator picks up a ticket and works it"
process is real (Client Requests queue in ops); a live status feed back to the customer, and a
reply channel, are proposed and not observed anywhere in either portal.