Microsoft 365 backup and recovery testing
Know your backups restore before you need them to.
The agreed restore scenarios are actually run. Recovery time is measured, the restored data is checked, anything that fails gets a named owner, and the recovery runbook is updated to match.
- What you get
- Recorded restore exercises, an updated recovery runbook and assigned corrective actions.
- How it starts
- A free scope call. The price is fixed in writing before anyone is given access.
- When it is done
- Each agreed recovery scenario is executed and logged; restored data is checked and failed checks have named corrective actions.
Illustrative sample · constructed example
A restore result belongs to one named scenario.
SharePoint file · approved isolated restore target
Selected check
Does the restored file satisfy the checks for this scenario?
| Record | Evidence or responsibility | Sample review |
|---|---|---|
| Selected backup | Identify the backup and the item agreed for the exercise. | Backup selected |
| Restore target | Restore into the isolated target and retain the time record. | No restore observed |
| Access and usability | Open it as the intended user and compare the content. | Access test pending |
| Business recovery | Relate the exercise to the wider recovery requirements. | Separate target review |
A restored item is not a demonstrated business recovery time. Access and usability also need evidence.
- Evidence
- Backup job reports success; no restore or access test has been observed.
- Decision
- Recovery remains unverified
- Next action
- Run the agreed safe restore and record start/end times and validation results.
Illustrative timing, not achieved performance. One file restore does not establish whole-business recovery time.
Open the complete illustrative document to inspect its fields and print a copy.
Open the sample documentWhy now
The work starts here.
Backups exist, but nobody has completed and accepted a useful restore scenario.
Scope at a glance
- One existing backup platform
- Microsoft 365 workloads only
- Client provides approved test targets
If nobody acts
What waiting costs
A job that reports success confirms data was written. It says nothing about whether that data can be read back into a working mailbox or site.
With no restore run and timed in this tenant, the recovery time quoted to a board, an insurer or a customer contract is an estimate.
Permissions, version history and folder structure can come back differently from the content they belong to. A restored site can be readable and still leave the team unable to work in it until access is rebuilt by hand.
Restoring for the first time during an incident means learning the restore path while the business is down. The people learning it are the same ones handling the incident.
Restoring over live data and restoring into a separate place are different operations with different consequences. Where neither has been agreed in advance, that choice gets made while the business waits.
Check your own environment
Sounds like you?
- Backup jobs report success, and that is the only evidence anyone has
- The recovery time in the continuity plan was estimated, never measured
- No restore has ever been accepted by the person who owns the data
- The runbook describes a platform version or process that no longer exists
Save yourself the call
Not for you if
- Restores are tested on a schedule and the times are written down
- There is no backup in place yet, which has to come before testing one
- Something is happening right now, which needs incident response and not a planned review
The work
What is different when we hand over
The restore scenarios that matter are agreed first: which mailboxes, sites, and data sets, restored to where, accepted by whom.
Each agreed scenario is executed against approved test targets, and the recovery time is measured rather than estimated.
Restored data is checked against the original by someone who can tell whether it is actually useful.
Every failed or degraded restore is assigned a corrective action with an owner and a date.
The recovery runbook is updated to match what the tests actually showed.
Acceptance
Checks before handover
Done when every agreed scenario passes, or a named corrective action has an owner and a date.
Backup coverage is verified system by system
Each agreed restore scenario has been executed and timed
Restored data is checked against the original
Anything that fails the test is written up with a fixed price to put it right
A fair question
Our backups run every night and report success. Is that not proof?
It is proof the backup job finished, which is not the same as proof you could get the business running again. A successful job can still produce data that will not restore, restore into a system that no longer exists, or take three days when the business assumed three hours. This measures the actual recovery, so the number you quote is one you have seen.
Price and calendar
Scope, price and project calendar
Engagement price
Price fixed after a short scope call.
The price is agreed in writing before any work starts and before anyone is given access. The call itself costs nothing. What moves the number:
What determines the scope
- Number of systems in scope
- Number and complexity of restore scenarios
- Whether the detection and escalation path is included
- Volume of data to check after restore
Scope & responsibilities
What is and is not included
The exclusions, what we need from you, how change is staged and reversed, and what is handed over at the end.
Exclusions
- Live incident response or forensics
- Production failover or destructive testing
- On-premises, immutable-storage, or cross-platform recovery engineering
- SOC monitoring
- Building a backup platform where none exists: that is a separately scoped Recovery Foundation engagement
What we need from you
- Provide approved test users, sites, and data
- Approve the restore scenarios before testing begins
- Provide access to the backup platform
Change and rollback method
- Restores run against approved test users, sites, and locations inside agreed windows; production data is not overwritten.
- Nothing destructive: the tests read from backup and write to agreed test targets only.
- Failures stop the affected scenario and are recorded rather than retried silently.
What you keep at handover
- A System guide: the configuration as delivered, the checks that were run and the unresolved list
- The restore test log, scenario by scenario, with measured recovery times
- Validation results for each restored data set
- The failure register, with a named corrective action, owner, and date per entry
- The updated recovery runbook
Access, acceptance and support arrangements
How you know the work is good
Judge it by what you can inspect.
The method is written down, the sample records open and the demo can be broken on purpose. Read it the way your technical owner would.
- 01How a project runs
A first conversation, free. An agreed scope with a named technical lead in the proposal. The price fixed in writing before we are given access. Checks before handover.
How we work- 02What is checked
Release checks, access test matrices and ownership maps. Constructed inspection records on the service pages show the standard before you buy.
See sample deliverables- 03What you keep
A System guide: what was agreed, what changed, what was tested and what remains open. With it, the scripts and check results behind the work.
Next step
Start with a free scope call.
Tell us what needs to change, what must keep working and the deadline. The call is free, and the price is fixed in writing before anyone is given access.
Price the recovery testOr write to [email protected]