Backups you have watched restore.
Servers, endpoints and Microsoft 365, restored in a test on a schedule — because a backup nobody has ever restored is a belief rather than a control.
How it is set up
Backup fails in two ways and only two. Either it was not running and nobody noticed, or it was running and could not be restored in time. Everything below exists to close one of those two.
What is covered
Servers, endpoints, Microsoft 365, and the line-of-business applications with their own peculiar requirements. The list is agreed at the start, because the gap between what people assume is backed up and what is backed up is where the bad days come from.
Restore testing on a schedule
We restore real data on a regular cycle and record the result. A backup job reporting success proves that a file was written. It does not prove that anything can be read back.
Retention and immutability
Copies that cannot be altered or deleted within their retention window, including by an administrator account. Modern attacks go looking for the backups first, and an editable backup is the same as no backup.
Recovery times agreed in writing
How long until you are working again, and how much recent work you would lose. Both are decided by you against cost, written into the agreement, and tested against reality rather than hoped for.
Microsoft 365 handled separately
Exchange, SharePoint, OneDrive and Teams backed up independently of the platform, with retention you choose rather than the default that quietly expires.
A written recovery runbook
Which system comes back first, who is called, what is communicated to clients and in what order. Written while it is calm.
Off-site copies
Because a fire, a flood or a burglary takes the server and the backup sitting next to it in the same trip.
An annual rehearsal
Once a year we run the whole thing as if it had happened, including the parts that involve people rather than machines. It is the only way to find out that the runbook lists a phone number nobody answers any more.
The two failures worth planning for
The first is quiet. A backup job started failing after an update in March, the alerts went to somebody who left in April, and nobody looked until the day a server died in September. This is common, it is entirely preventable by monitoring the backup rather than trusting it, and it is the first thing we check when we take a company on.
The second is loud. The backups exist, they are complete, and restoring them takes eleven days because nobody had ever measured how long it takes to pull several terabytes back over that connection. The data was never lost. The business simply could not operate for a fortnight, and no insurer will refund that.
Both failures are found by testing rather than by buying better software. Which is why the schedule, the measured recovery times and the annual rehearsal are the part of this service that actually matters, and the storage is more or less a commodity underneath them.
Whether this is the right service for you
This is usually the right shape when
- Backups you have never seen restored
- No agreed answer to how long recovery would take
- Ransomware appearing on the risk register or the insurance form
- A regulatory or contractual retention obligation you cannot demonstrate
We would point you elsewhere if
- Wanting only storage with nobody accountable for restoring from it
- Environments where the required recovery time is measured in seconds, which needs a high-availability design and not a backup product
Questions about backup & recovery
How often do you actually test a restore?
What is the difference between RTO and RPO?
Does this cover ransomware?
Do you back up laptops as well as servers?
Start with a free IT assessment
Thirty minutes on a call, then a written picture of what you are running, where you are exposed, and what supporting it properly should cost per month. No obligation, and the document is yours to keep either way.