Your practice
You choose the backup platform and retention policy, decide what counts as an acceptable restore-test result, and name who gets told immediately if a restore test fails.
Backup & disaster recovery Sauvegarde et reprise
A backup nobody has tried to restore is a hope, not a plan.
Backup already runs somewhere for most clients; what’s usually missing is someone who checks it succeeded and someone who’s actually tried a restore. This page names backup monitoring and scheduled restore testing as their own priced, recurring line — with the same recurring artifact and named-approver escalation as every other request on this site, not a one-time project.
Delivery team
We confirm the agreed backup jobs actually completed, run the scheduled restore test against the policy you set, and escalate a failed test the same way we escalate any other risk — before the next backup cycle, not after.
Backup monitoring and restore testing
For a client who already has backup running — locally, in the cloud, or both — but whose job-completion status and restore reliability nobody has checked on a schedule.
What we need first
Read access to the backup platform’s job history (or a defined report path), the retention policy and restore-time expectation you want enforced, and a named approver for a failed restore test or a job that’s been silently failing.
What’s included
- Checking agreed backup jobs completed on schedule, across the systems in scope
- A scheduled restore test against the policy you set, with the result recorded
- A recurring backup-and-restore note you can forward to the client as-is
Handled separately
- Choosing or licensing the backup platform, or its storage costs
- Approving a full disaster-recovery failover without the named approver’s sign-off
- Treating a confirmed data-loss event as a routine restore test rather than an escalation
What you get: Backup that’s been verified on a schedule instead of assumed — and a restore test with an actual result, not just a job log that says "completed."
What we hand back: A recurring backup-and-restore-test note, in the account’s declared language, that names what was tested and what the result was.
What has to be agreed before backup becomes a priced line
What "restored successfully" means
A file that opens and a system that boots into a usable state are different bars. Agree on what a passing restore test actually has to demonstrate before the first test runs.
Recovery point and recovery time expectations
How much data a client can afford to lose, and how long they can be down, changes what backup frequency and restore method are even appropriate — this is a business decision, not a technical default.
Which systems are actually in scope
A line-of-business application with its own database, or a system living outside the main environment, needs to be named explicitly — "we back up the server" doesn’t automatically mean everything on it is restorable.
What triggers a full DR conversation
A single failed file restore and a site-wide outage are not the same request. Name the line between "log it and retest next cycle" and "escalate now" before there’s a real outage to sort it out during.
What this line doesn’t include
- A guaranteed recovery time or recovery point objective
- Backup storage, licensing, or hardware costs
- Emergency full-environment failover outside a scoped, agreed DR exercise
Straight answers on backup and disaster recovery
Do we need to switch backup platforms to use this?+
No. This works with the backup platform and schedule your client already has — we monitor and test against it, we don’t sell or require a specific tool.
What happens when a restore test fails?+
It goes to the named approver as an escalation, the same way a failed patch or a security exception does — with what’s known about why, so your practice can decide the next step. It doesn’t just get quietly rescheduled for next cycle.