Backup & Business Continuity
Backup is not the point. Getting back to work is.
Almost every organization has backups. Far fewer have ever restored from them. The difference only becomes visible on the worst day of the year.
Let's talk
What this fixes
If any of this sounds familiar, this is the conversation
Backups report success and nobody checks
A green tick means the job ran. It does not mean the data is complete, usable, or recoverable inside a timeframe the business could survive.
Nobody can say how long recovery would take
Ask what happens if the main system disappears at 9am and the answer is an estimate, not a tested number.
The plan lives in one person's head
If the person who knows the recovery sequence is unreachable, the response starts from scratch under maximum pressure.
Cloud data is assumed to be safe
Data in Microsoft 365 or a SaaS platform is often outside the backup scope entirely, because everyone assumed the vendor was handling it.
What changes
What the business gets, not what the software does
- You know, per system, how long you would be down and how much data you would lose
- Restores are proven on a schedule rather than assumed
- The response is a documented procedure anyone senior can follow
- Insurers and customers get evidence instead of assurances
- Recovery spend is aimed at the systems that actually stop the business
Accountability
What we take responsibility for
Written into the scope before you sign, so there is no argument later about who owned it.
We own this
- Backup configuration, monitoring, and failure follow-up for systems in scope
- Scheduled restore testing and the written evidence of each test
- The recovery runbook, kept current as the environment changes
- Coordination of the technical response during an incident
What is included
- A business impact conversation: which systems stop the business, and after how long
- Agreed recovery time and recovery point targets per system
- Backup configuration for servers, endpoints, and cloud data in scope
- Monitoring of backup jobs with follow-up on failures
- Scheduled test restores, with results written down
- A recovery runbook naming systems, sequence, and responsibilities
- An annual review of the plan against how the business has changed
Not included, or depends on scope
- Storage and cloud retention costs, which scale with how much you keep and for how long
- Standby infrastructure for very short recovery targets, which is a separate cost decision
- Full disaster-recovery rehearsals involving your staff, which are scheduled and quoted separately
- Application-specific recovery supported by that vendor, where we coordinate the sequence
- Regulatory retention requirements, which change design and cost
How it works
How the engagement runs
Agree what down time costs
System by system, we establish how long you could operate without it and how much data you could stand to lose. Everything else follows from those two numbers.
Build backup to match
Design is driven by those targets rather than by a default schedule, and covers cloud data as well as servers and endpoints.
Test the restore
We restore on a schedule and record what was restored, how long it took, and anything that needs to change.
Write it down
The runbook names systems, order, owners, and contacts, so the response works even when the usual people are unreachable.
Honest fit
Who this suits, and who it does not
We would rather tell you now than three months into an engagement neither of us enjoys.
A good fit if…
- An outage of a day or more would cause real financial or contractual damage
- You need evidence of tested recovery for insurers, customers, or a board
- You have cloud data that may not currently be backed up at all
- You want recovery targets agreed rather than discovered
Probably not right if…
- You want the cheapest possible backup with no testing attached
- You are unwilling to spend time agreeing which systems matter most
- You need near-instant failover but do not want the standby infrastructure it requires
Getting started
What the transition actually looks like
Changing providers is the part everyone dreads. Here is each phase, what we need from you, and how disruptive it is.
Understand
Step 01 of 4We go through what you have, what is breaking, and what the business is trying to do. We talk to the people who actually use the systems, not just whoever manages them.
- What we need from you
- Access to your current setup, time with a few key people, and an honest account of what frustrates you.
- What you get
- A written summary of what we found, including anything we think you should know before deciding to work with us.
Disruption to your business
None. Nothing changes during this phase, we are looking, not touching.
Straight answers
Questions we get about backup & business continuity
How often do you actually test restores?
Is our Microsoft 365 data backed up?
What is the difference between backup and continuity?
How much should we spend on this?
Wondering if backup & business continuity is what you need?
Describe what is going wrong. If this is not the right answer for you, we will say so rather than sell it to you.