Backup that has actually been tested.
A backup is a claim. A restore is proof. Plenty of businesses discover the difference on the worst possible day, when the backup that "ran every night" cannot actually bring anything back. This page walks you through how we design, deploy and, most importantly, test backup: encrypted, kept off site, immutable against ransomware, and restore-tested on a schedule rather than assumed.
Five phases, proof included.
The mapWhat is actually at risk
No chargeWe map where your data really lives: servers, laptops, and the part most businesses miss, Microsoft 365 itself. Email, Teams and SharePoint are not backed up by Microsoft in the way people assume; a deleted mailbox or a ransomware-encrypted SharePoint library needs your own backup to come back from. Then two questions size everything: how much data can you afford to lose, and how long can you afford to be down?
- Those two answers, honestly: hours or days, for both
- Anything with a legal or industry retention requirement
- What backup you believe you have today; we will check whether it is true
Design & scoping: the plan and the price
Price is fixed hereWe design the backup to match your answers: what is covered, how often it runs, how long copies are kept, and where they live, encrypted and off site, with immutable copies that ransomware cannot alter or delete. We work across four proven platforms and pick the fit, not the favourite. The scope fixes the monthly price.
- What is covered: servers, Microsoft 365, endpoints, each named
- Frequency and retention, matched to your loss tolerance
- Where copies live, and which are immutable
- Monthly cost, and what a restore costs: nothing extra
- Sign-off on the recovery targets; they drive the price
- The retention call where the law does not decide it for you
Deployment
No disruptionBackup agents are deployed quietly and the first full copy runs, usually over days in the background so it does not choke your internet connection. Nobody's work changes; most teams never notice this phase happened.
- Agents deployed to servers, Microsoft 365 and endpoints in scope
- First full copy seeded, bandwidth-throttled during work hours
- Alerting wired up: a failed backup pages us, not a log file
The restore test
The proofBefore we call the project done, we restore something real: files, a mailbox, or a whole server to a sandbox, and we time it. You see the evidence, and the measured time becomes your known recovery time, not a hope. A backup that has never been restored is a rumour, and we do not hand over rumours.
- A real restore, performed and timed
- The result documented and shared with you
- Anything that fell short fixed and re-tested before handover
Run, watch, re-test
Ongoing, foreverBackups are monitored daily and failures are chased the day they happen, because a backup that quietly stopped three weeks ago is the classic disaster story. Restore tests repeat on a schedule, and when you need something back, from one deleted file to a whole system, that is what the whole arrangement exists for. Just ask.
- Daily monitoring; failures chased same day
- Restore tests on a schedule, results reported
- Coverage reviewed as systems are added or retired
- Any restore, any size, included in the service
What you can hold us to.
Both ways- Encrypted, off-site, immutable copies as the baseline, not the upgrade
- A real restore performed and timed before we call it done
- Failed backups chased the day they fail
- Restore tests repeated on a schedule, with the results shared
- Honest answers on how much loss and downtime you can carry
- Tell us when systems change, so coverage follows
- Treat the restore-test reports as board reading, not filing
Find out what your backup
would really do.
The assessment costs nothing, and the most valuable thing it produces is the honest answer to one question: if today went badly, what would actually come back?
