Servers, Backup & Disaster Recovery
Disaster Recovery & Business Continuity
We build a disaster recovery plan that answers one question: what happens in the next hour. We define scenarios, the order systems come back, an owner for every step and a fallback way of working, then test it in controlled conditions so each step has a measured duration rather than a promised one.
Who it is for
- Businesses where a day of downtime has a measurable cost
- Companies with ERP or production dependent on systems
- Organisations that have backups but no plan
- Boards wanting a written answer on what happens during an outage
When we are NOT the right choice
- If there is no working backup as a foundation
- If owners and authorities per step cannot be nominated
- If there is no willingness to test the plan
PROCESS
The process
Indicative times from signature of the proposal, subject to hardware availability. Every project is shaped to the size and the needs of the client.
01Impact analysis
We separate what must return first for the business to function from what can wait. It is rarely what people expect.Time: 2-5 working daysDeliverable: Systems ranked by criticality
02Scenarios and recovery order
We write scenarios, from a disk failure to ransomware and loss of access to the premises, each with a specific sequence of actions.Time: Alongside the studyDeliverable: A plan per scenario with steps
03Owners and communication
We define who decides, who executes and who informs, along with a fallback communication route if the systems are down.Time: Alongside the studyDeliverable: Owner and contact table
04Testing the plan
We run the plan in controlled conditions and record how long each step took. That is where the gaps surface.Time: 1-2 weeks alongside backupDeliverable: Test report with real durations
05Maintaining the plan
The plan is updated when systems or people change. A two year old plan that was never revised is close to useless.Time: Per reporting periodDeliverable: Updated plan and repeat testing
What is included
- Impact analysis and system ranking
- Failure scenarios with recovery sequence
- Owner, authority and contact table
- Fallback way of working during an outage
- Plan testing with measured durations
- Periodic updating and repeat testing
What is not included
- Insurance cover and claims handling
- Legal services and regulatory notifications
- Forensic incident investigation
- Cost of standby equipment and premises
Technology and equipment
- Veeam
- Proxmox
- Synology
- Microsoft 365
- Microsoft Azure
- Windows Server
From practice
Most disaster recovery plans fail at two points that are not technical. The first is that nobody knows who decides. The second is that the plan is stored on the server that just went down.
Testing brings both to the surface, along with the real durations. Almost always, the step that takes longest is not restoring the data but waiting for a decision, or for a credential nobody can find.
Prerequisites
- A working and tested backup
- Nominated owners and authorities
- A window to test the plan
- A decision on the acceptable cost of downtime
Cost
The study and first test are quoted as a project. Maintaining the plan and repeat testing sit within the support agreement. Standby equipment or premises are costed separately and depend on the RTO targets you set.
We do not publish a price list. Every proposal follows a site survey and separates hardware from labour.
What moves the cost
- Number of critical systems
- Required RTO per system
- Whether standby infrastructure must be kept ready
- Frequency of testing
Frequently asked questions
What is the difference between backup and disaster recovery?
How often should it be tested?
Do we need a second site?
Does it cover ransomware?
NEXT STEP
Build the plan before you need it
We start with impact analysis: what must come back first, how quickly, and who does it.
GET IN TOUCH
Tell us what you need
Four fields. An engineer replies, not a sales desk.