Start with the right questions
Before talking technology, you need two numbers for each application: how much data you can afford to lose (RPO) and how long you can afford to be down (RTO). A payroll application that can wait half a day doesn't call for the same architecture as an online ordering site. Without those numbers, you either overbuild or, more often, find out on the day of the outage that the solution in place doesn't meet expectations.
The building blocks
Solid backups
They are the foundation of any continuity plan: full, differential and log backups at the right frequency, off-site copies, encryption, integrity checks. Many companies need nothing more, provided all of it is actually tested.
Log shipping
A copy of the database kept up to date on a second server by regularly restoring transaction log backups. Simple, available in every edition, and ideal for a disaster recovery site.
Always On availability groups (AG)
Synchronous or asynchronous replication to one or more replicas, automatic failover, and readable secondary replicas to offload reporting. The most complete option, and one that demands careful design and disciplined operations.
Failover cluster instances (FCI)
The entire instance fails over from one node to another on shared storage. Still relevant in some infrastructures, and often combined with an availability group for the disaster recovery site.
Azure
Azure SQL Managed Instance and Azure SQL Database have high availability built in and offer geo-replication and failover groups. On-premises SQL Server can also use Azure as its disaster recovery site.
An untested SQL Server DR plan is not a DR plan
Real outages always expose what the diagrams leave out: a SQL Agent job that only exists on the primary node, a login missing from the secondary, an application pointing to a server name instead of the listener. That's why every implementation ends with a documented failover test, along with written procedures your team can follow without us.
The ransomware threat
Ransomware attacks now go after backups first. Backups that production accounts can reach will be encrypted right along with production. We check how isolated your copies are, which accounts can access them and, above all, whether you can restore everything within an acceptable timeframe.
Already have an architecture in place?
We can review it: synchronization health, consistency of server-level objects across replicas, listener and failover timeout configuration, and how well it fits your targets. This check is part of our SQL Server audit, and ongoing monitoring is included in our remote DBA services.
