Reliability
High Availability and Disaster Recovery: Tested Beats Configured
Every estate has a diagram showing failover. Far fewer have a date on which it last worked. What real database high availability and disaster recovery involve across SQL Server, Oracle, PostgreSQL and MySQL, and how to know yours will hold.
By RadixTrie3 September 20262 min read
Ask most organisations whether their databases are highly available and the answer is yes, followed by a diagram. Ask when the failover was last performed on purpose, and the room goes quiet. High availability and disaster recovery are not features you configure once; they are capabilities you prove regularly. This article sets out what that means in practice, platform by platform, and how to tell whether your protection would actually hold.
Start with two numbers
Every database needs a recovery point objective, how much data the business could afford to lose, and a recovery time objective, how long it could be unavailable. Written down, per system, and agreed with the people who own the business process. Everything else follows from these two numbers: whether you need synchronous replication or a nightly backup is enough, whether a second data centre or cloud region is justified, and how much the protection may cost. Without them, HA and DR designs are guesses dressed as architecture.
High availability is not disaster recovery, and neither is backup
- High availability handles the failure of a server or service with minimal interruption, usually within one site or cloud region, using replicas and automatic or scripted failover.
- Disaster recovery handles the loss of a whole site, region or environment, usually with a longer recovery time, from a separate location.
- Backups handle the cases the other two cannot: corruption, accidental deletion, ransomware and human error, all of which replicate happily to every standby you own.
A sound design has all three, and a support team that tests all three.
The building blocks, by platform
- SQL Server: Always On availability groups for readable, fast-failover replicas; failover cluster instances for instance-level protection on shared storage; log shipping as a simple, robust disaster recovery layer. Edition determines what is available.
- Oracle: Data Guard physical standby databases for disaster recovery and switchover, and Real Application Clusters for node-level availability, both Enterprise Edition capabilities. Standard Edition estates need a different design.
- PostgreSQL: streaming replication to hot standbys, with cluster managers such as Patroni or repmgr handling failover, plus write-ahead log archiving for point-in-time recovery.
- MySQL and MariaDB: asynchronous or semi-synchronous replication, Group Replication and InnoDB Cluster for MySQL, Galera Cluster for MariaDB, with binary log retention supporting point-in-time recovery.
The technology matters less than the drill. A standby that has never been promoted is a hypothesis. Schedule the switchover, time it, involve the application team, and write down what broke.
What testing looks like when it is done properly
- Restore tests on a schedule: a full restore plus point-in-time recovery to a test server, with the elapsed time recorded against the recovery time objective.
- Planned switchovers of high-availability replicas during agreed windows, with applications reconnecting and being checked, not just the database coming up.
- Disaster recovery exercises at least annually, invoking the secondary site or region as if the primary were gone, including DNS, connection strings, jobs, integrations and the people who need to be reachable.
- Evidence kept for each: what was tested, when, by whom, how long it took and what was fixed afterwards. Auditors ask for this; so should the board.
Common failures found in drills
Replicas that stopped replicating months ago without anyone noticing. Standby servers patched to a different version from the primary. Application connection strings hard-coded to one server. Jobs and integrations that only exist on the primary. Backups stored on the same storage as the database. Credentials and firewall rules that only work from the primary site. None of these appear on a diagram; all of them appear in a drill.
How RadixTrie approaches HA and DR
High availability, disaster recovery and backup validation are part of RadixTrie's <a href="/services">support and managed DBA services</a> across SQL Server, Oracle, PostgreSQL and MySQL/MariaDB. Senior engineers design to the recovery objectives the business actually agrees, and then run the restore tests and switchovers on a schedule so the capability stays real. A <a href="/blog/database-health-check">database health check</a> is the usual starting point when nobody is sure what the current protection would do.
<strong>Related reading:</strong> <a href="/blog/database-health-check">The Database Health Check: What a Good One Covers and What It Finds</a> · <a href="/blog/sql-server-support-south-africa">SQL Server Support in South Africa: What Good Looks Like</a> · <a href="/blog/oracle-database-support-south-africa">Oracle Database Support in South Africa: Keeping Licensed Estates Healthy and Compliant</a> · <a href="/blog/mysql-mariadb-support-south-africa">MySQL and MariaDB Support: Where Small Databases Cause Big Outages</a>
TAGSHigh AvailabilityDisaster RecoveryBackupSQL ServerOraclePostgreSQLMySQL