We make backups but never tested if we can actually restore.
An untested backup is an assumption. The question isn't whether you back up, but whether you can restore inside your RTO.
Try this first
- 1Schedule a real restore test on staging, not production. Pull a backup from X days ago out of your tool or off-site storage.
- 2Restore the DB first on staging. Verify the site starts, admin works, no schema conflicts.
- 3Then restore files. On file-heavy sites (lots of media, uploads) this is where time goes.
- 4Click through at least five flows: homepage, contact, login, a blog post, a product page if you're a shop. Does it all work, or is content missing.
- 5Time it. From decision to working restore, how long? Compare to your RTO. Too long? Optimise (more recent snapshots, parallel restore, better tooling).
- 6Write the runbook. Who does what, which credentials, in what order. In a real crash you have no time to improvise.
When to bring us in
Revenue-critical site or SLA with customers? A DR plan with verified RTO/RPO and quarterly drills is real work. An infra engineer or DR-providing MSP is worth the spend.
See also
- WordPress, plugins and theme have gone 6+ months without updatesOut-of-date WP is the number-one entry for malware. Don't just hit 'update all', back up first.
- Theme update broke the layout or threw a fatal errorThemes overwrite custom CSS on update unless you use a child theme.
- WordPress shows a blank screen after a plugin install or updateWSOD (white screen of death) is usually one crashing plugin. You isolate it.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.