A backup job that exits green is a claim. The claim is that, on some future morning, those files will become a working site. I do not believe the claim until I have done the morning on purpose, on a scratch machine, while nobody is waiting. An untested backup is a story you tell yourself. A restore you have run is a backup.
Restore to nothing, on a schedule
The scratch environment is not production and not the staging site editors use. It starts empty. The backup is the only way in. I bring it up, log in, and walk one path that would matter during an incident: an order page, a form submission still in the database, a media file that is supposed to be in the archive and not only on the old disk. Then I throw the scratch copy away.
If that fails, I would rather learn it on a Tuesday than during the outage the backup was for. The usual failures are dull. The database dump is newer than the uploads. A plugin table references a file that was excluded. The archive assumes a PHP version the scratch host does not have. None of these show up in the green tick of the backup plugin.
Updates need a way back
Taking an update is easy. Taking an update with a way back is the service. A snapshot before, a short smoke test after, and a written rollback if the smoke test fails. Saying the backup can be restored is not a rollback unless the restore has a duration you have measured. I want that duration from the scratch run, not from the plugin’s brochure.
What I actually open on the scratch copy
Login as a real user, not as the install admin, if the backup includes users. Open an order that has a status, a total and at least one note. Open a page that contains an image, and confirm the image is the file from the archive rather than a hotlink back to production. Submit nothing. I am checking that the past came back, not creating a new present on a throwaway host.
I write the duration next to the date. “Last restore, 18 minutes, failed on the uploads archive, fixed the exclude, reran.” That note is more useful than a monitoring badge. When someone asks whether the plan includes backups, I can answer with a date. A plan that cannot answer with a date is a cron job with an invoice.
A response time in a care plan is meaningless on day one if I have not yet restored anything. The clock I am willing to write down starts after the baseline, the access, and a restore that has succeeded. Before that, I am still learning how the site is put together. Promising a same-day answer in that fog is how care plans become apologies.
Ask when the last test restore was run. The pause before the answer is the answer.
Care is not an open tab for new features
A plan that promises monitoring, updates, restores and also whatever you think of next is priced for a fantasy, or it will be renegotiated the first time the fantasy arrives. New pages, a redesign, a migration: those are their own scope. The plan I will stand behind is narrower. The site keeps doing what it already does. The backup has been proven. A person answers inside the hours that were written down. That is less exciting than a retainer with no edges. It is also a plan you can check.
