A multi-clinic group moves its practice-management SQL Server to Always On with point-in-time restore
A healthcare group of 12 clinics with about 700 staff.
- Scale
- ~600 GB across 5 databases, 2 synchronous replicas plus 1 asynchronous disaster recovery replica
- Engagement
- 6 months, with cutover in one weekend
The challenge
The practice-management database ran on one aging SQL Server with nightly backups. A failure would lose a day of records and take clinics back to paper, and the team had never timed a restore.
What our team delivered
- An availability group with two synchronous replicas in the primary data center for automatic failover and one asynchronous replica in a second region for disaster recovery
- Full, differential and transaction log backups every 15 minutes, with backup checksums, so any point in time can be restored
- A scheduled restore to a separate server, followed by DBCC CHECKDB, with the elapsed time recorded against the recovery objective
- Encryption in transit and Transparent Data Encryption, with keys stored apart from backups
- The move itself rehearsed twice, with a rollback plan and a final cutover in one weekend window
- Monitoring for replica health, log send queue and backup age, with alerts to named engineers
Result
A failed replica is now a routine alert rather than an outage, and a restore to a chosen minute has been performed and timed. The clinics know their recovery point and time because they were measured.
Backup tiers: data lost versus time to recover
Recovery point objective (RPO) is how much recent data a restore loses; recovery time objective (RTO) is how long the restore takes. Faster tiers sit close to the production system and share its fate; slower tiers survive ransomware and site loss. The scale is logarithmic. Illustrative figures.
Failover in under a second
ISP A fails at 300 ms. BFD (RFC 5880) with a 50 ms interval and multiplier 3 declares the session down 150 ms later, BGP withdraws the routes, and the forwarding table repoints to ISP B. Traffic is back at full rate in well under a second; without BFD the router would wait for the 90 s BGP hold timer. Illustrative figures.
Every sign-in, verified
Staff sign in once, but behind the scenes the device, the identity, a phone approval and your access policy are all checked before any app opens, and strangers are turned away.
Facing something similar?
Tell us about your environment. We will tell you plainly what we would do and what it would take.