The problem
A Yorkshire law firm''s practice management server wouldn''t boot. Windows Server 2012 R2, hosting SQL Server 2016 Standard — the primary database behind everything the firm used to run cases, bill clients and manage documents. A corrupted boot file had put Windows into a restart loop with no way out.
The database data itself — the MDF and LDF files — sat on a separate physical disk, which was the one bit of good news. But there was no secondary SQL Server anywhere to load backups onto. No standby instance, no replica. Until we could get some SQL Server running, backups (if they''d had them) would have been unusable anyway.
The firm was effectively offline. Every hour of downtime meant fee earners couldn''t record time, receptionists couldn''t check case status, and nothing could be billed.
What we did
Rebuilt the server from bare metal. With the boot volume unrecoverable, the fastest route back was a clean install. We put a new disk in, installed Windows Server 2012 R2 fresh, and got the machine networked and stable. That took the first 24 hours — most of it Windows updates, drivers and licensing, not anything clever.
Reinstalled SQL Server 2016 Standard on the rebuilt OS. Configuration set to defaults — the priority was getting the practice management software talking to the database again, not tuning for performance. Tuning could come later.
Reattached the surviving MDF and LDF files from the untouched data disk. The database came up clean, the software reconnected, and the firm was back in business.
Took immediate backups and wrote them straight to an on-site external disk — because the very first thing to do after a recovery is make sure a second recovery won''t be needed. Then we sat down with the firm to talk about what should change so this couldn''t happen again.
The recommendation — and what we actually did
Our first recommendation was a managed instance of SQL Server in Microsoft Azure. Managed instances handle patching, high availability, and off-site backup as part of the service — exactly the failure modes that had just bitten them. But the firm''s practice management software had connection requirements that ruled out a cloud-hosted database. Sometimes the ideal answer isn''t available; you work with what is.
What we did instead: kept the SQL Server on-premises where the software needed it, and built a point-to-site VPN from the server to Azure. Every night at 20:00, SQL Server takes a fresh backup and writes it straight through the VPN to Azure File Storage. Off-site, encrypted, versioned, and completely independent of the physical building.
The result
The firm is back to running normally, on the same software they''ve always used, on an OS and database version that meet their software vendor''s requirements. Nothing about their day-to-day changed. What did change:
- Nightly off-site backups — an outage on the same scale would now mean restoring last night''s data onto a fresh server, not a bare-metal rebuild with fingers crossed
- A tested recovery path — we walked the firm through what a restore looks like so nobody has to invent it under pressure
- A written recovery playbook — steps, credentials, and Azure references documented in one place so any competent engineer could execute it, not just us
Backups nobody has tested are a hope, not a plan. This firm now has a plan.