Northallerton construction firm recovers from a server failure in under four hours
A 65-staff Northallerton construction firm recovered from a server failure in 3 hours 40 minutes with under one hour of data loss, keeping 12 live sites working the same day.
A hardware failure took out the file server holding drawings, programmes and site paperwork on a Tuesday morning. Because backups had been tested rather than assumed, the firm was working again the same day.
Client: 65-staff construction and civil engineering contractor. Name withheld under our confidentiality terms.
At a glance
- Client
- 65-staff construction and civil engineering contractor
- Sector
- Construction
- Location
- Northallerton, North Yorkshire
- Size
- 65 employees, 12 active sites
- Services
- Cyber Security Assessment, Business Continuity, EDR
- Timeline
- Recovery tested quarterly; live recovery in 3h 40m
- Headline result
- 3h 40m — Full recovery on the day of failure
Measured results
- Full recovery on the day of failure
- 3h 40mFull recovery on the day of failure
- Data loss window (recovery point achieved)
- < 1 hourData loss window (recovery point achieved)
- Live sites kept working the same day
- 12Live sites kept working the same day
- Restore tests per year, each timed and documented
- 4xRestore tests per year, each timed and documented
The challenge
- Site teams across twelve live projects depended on shared drawings and programme files.
- Backups ran nightly but had never been restore-tested.
- No documented recovery order: nobody knew which systems mattered first.
- A day of lost site productivity across twelve projects carries significant cost.
What we did
- 1
Ran a cyber security and resilience assessment covering backup, recovery and continuity, not just perimeter security.
- 2
Established recovery time and recovery point objectives per system with the leadership team.
- 3
Moved backups to an immutable, off-site copy that ransomware cannot encrypt or delete.
- 4
Documented a recovery runbook ordering systems by business impact, starting with file and drawing access.
- 5
Restore-tested quarterly, timing each test and correcting the runbook after every run.
- 6
On the day of failure: invoked the runbook, restored to standby infrastructure and verified data integrity.
The outcome
- Operations resumed the same working day with under an hour of lost data.
- Immutable off-site backups remove the ransomware path to the recovery copy.
- The recovery runbook is a living document, corrected after each quarterly test.
- Continuity evidence now supports pre-qualification questionnaires on public sector work.
“We had backups for years and never once tried restoring them. The first time we tested, it took nine hours and half of it did not work. That is what we fixed.”
The concepts behind this engagement
Plain-English reference pages explaining the certifications, threats and controls involved in this piece of work.
Where this fits in what Complete Cyber Security does
FAQ
Questions about this engagement
The questions businesses in a similar position ask most often before starting.
Why do untested backups so often fail when they are needed?
+
Because a backup job reporting success confirms that data was written, not that it can be read back into a working system. The common failures are predictable: a database backed up while running and therefore inconsistent, a virtual machine restored without its network configuration, an encryption key stored only on the server that was lost, or a retention policy that quietly stopped covering a critical share after a migration. None of these appear in a nightly success report. A timed quarterly restore test surfaces them while it is inconvenient rather than catastrophic. This firm's first test took nine hours and partially failed.
What does immutable off-site backup protect against?
+
Modern ransomware deliberately targets backups before encrypting production, because an attacker who destroys your recovery copy converts a recoverable incident into a ransom negotiation. Immutable storage means the backup copy cannot be altered or deleted for a defined retention window, even by an administrator account with valid credentials. Combined with an off-site copy, it also covers physical events such as fire, flood or the hardware failure that occurred here. The rule of thumb remains three copies of data, on two different media, with one off-site and immutable, and at least one copy tested regularly.
How do you decide what recovery time is acceptable?
+
By working out what an hour of downtime actually costs in your business, then buying against that number rather than an arbitrary target. For this contractor the calculation was straightforward: twelve live sites, each with crews unable to work without current drawings and programme information, made a full day's outage very expensive and a four-hour outage absorbable. That set a four-hour recovery time objective for file and drawing access, and a longer objective for back-office systems that could wait. Setting objectives per system, rather than one blanket target, keeps the cost of standby infrastructure proportionate.
