We build a script that periodically verifies your backups are actually restorable, not just that they completed — running on an ongoing schedule after we’re done, which means this joins the same category as any persistent automation: someone needs to own its continued operation and notice if it stops flagging results.
A verification script that silently stops running is worse than no script at all
If this script stops running and nobody notices, you’re left believing your backups are being verified when they’re not — a false sense of security that’s arguably worse than never having automated verification in the first place. We’ll document clearly how to confirm it’s still actually running, and that check is yours to make periodically, not something we do on your behalf indefinitely.
Automated backup verification script
A script that actually verifies backups restore — with a way to confirm it's still running.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- Access to your existing backup system and its stored backups
- A staging or isolated environment where verification restorations can safely run
- Confirmation of who should be notified of verification results, and how
This or something else?
| You want an ongoing, automated script that periodically verifies your backups actually restore correctly | This fix covers it |
| You want a one-time restoration test done now, not an ongoing automated script | Backup restore test & verification report, in the Backups, Staging & Migration Ops category, the one-time version |
| You don’t have a backup system set up yet at all | Backup system setup & schedule configuration, the prerequisite step |
| Your backups are failing to run at all, not a question of restoration quality | Backup failure diagnosis |
What we do
- Confirm your backup schedule and an appropriate, corresponding verification schedule
- Build a script that performs an isolated test restoration on that schedule
- Configure result logging and notification to your specified recipient
- Test the script’s first scheduled run to confirm correct behaviour
- Document how to confirm the script itself is still running as expected
- Provide written ownership documentation covering what it does and how to check on it
What is included
- An ongoing, scheduled backup verification script
- Result logging and notification configured to your specifications
- Verified first successful run
- Written documentation on ownership and how to confirm it’s still running
Not included
- Ongoing, indefinite monitoring of the verification script itself by us — that responsibility transfers to you
- Fixing an underlying backup system failure this script might reveal — a separate, related fix at that time
- Performing manual restoration if the script confirms a backup is unrestorable — a separate, related fix if that happens
- Guaranteeing the script continues working indefinitely as your backup system or hosting environment changes
Questions about this fix
Isn't the whole point of this that I don't have to think about it anymore?
The script itself runs without your daily attention, which is the genuine benefit — but you do need to periodically confirm it's still actually running and producing results, since a verification tool that silently stops verifying gives you false confidence rather than none at all.
What happens if a verification run finds a backup that can't actually be restored?
That's exactly the kind of result the notification is built to surface — at that point it becomes a separate, urgent fix to address the underlying backup system issue, rather than something this script resolves on its own.
How do I check that this script is genuinely still running months from now?
We document a specific, straightforward way to confirm this — checking a log, a notification history, or a status indicator — as part of this fix, precisely so it's not a mystery whether it's still working.
Will this slow down my live site by running restoration tests?
No, restoration tests run in an isolated environment specifically to avoid touching or affecting your live site during verification.
Is this worth it if I already trust my backup system?
Trust without verification is exactly the gap this fix closes — a backup system that's always reported success can still fail to actually restore correctly for reasons that only show up when someone genuinely tries, which is what this script does regularly rather than leaving to chance.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.