TABLE OF CONTENTS
- •Does your disaster recovery plan actually work?
- •Key Concepts at a Glance
- •HA, DR and Backups Don’t Replace Each Other
- •How to Set RPO and RTO
- •DR Options by Platform
- •What a DR Plan Should Contain
- •Drills: Prove the Plan Actually Works
- •Common Mistakes During a Disaster
- •Regulated Sectors
- •Disaster Recovery with Aryasoft
- •Frequently Asked Questions
- •Sources
- •Prove your plan with drills
A database disaster recovery (DR) plan is a document that defines how quickly, and with how much data loss at most, databases come back into service after a data center loss, a ransomware attack, serious data corruption or human error, and describes step by step how that happens. Its two key measures are RPO (the maximum acceptable data loss) and RTO (the maximum acceptable downtime). A plan that has never been tested is only a statement of intent.
This guide is for IT managers and business continuity teams at organizations running SQL Server, Oracle or PostgreSQL.
Does your disaster recovery plan actually work?
Aryasoft sets RPO and RTO targets for your databases with you, builds the right architecture and proves the plan with regular drills.
Key Concepts at a Glance
| Concept | Meaning | Example question |
|---|---|---|
| RPO (Recovery Point Objective) | The maximum acceptable data loss | “How many minutes of recent data can we afford to lose?” |
| RTO (Recovery Time Objective) | The maximum acceptable time to restore service | “Within how many hours must the system be running again?” |
| High availability (HA) | Service continues when a single server or component fails | Automatic failover within the same data center |
| Disaster recovery (DR) | Service comes up elsewhere when a whole site is lost | A standby system in a second data center or in the cloud |
| Backup | A copy of the data at a point in time | The last line of defense against logical errors and ransomware |
HA, DR and Backups Don’t Replace Each Other
The most common misconception is that a high availability solution also covers disaster recovery or backups.
| Scenario | Does HA protect? | Does DR protect? | Does a backup protect? |
|---|---|---|---|
| Server hardware failure | Yes | Yes | Yes (more slowly) |
| Data center loss (fire, flood, long power outage) | No (if on the same site) | Yes | Yes (if the backup is on another site) |
| Accidentally dropped table or a bad UPDATE | No; the error reaches the replicas too | No; the error reaches the DR system too | Yes |
| Ransomware | No | Often no | Yes, but only if the attacker can’t reach it |
| Logical data corruption | No | No | Yes |
Critical
In ransomware attacks, attackers go after the backups first. If your backups sit on a disk or share reachable with the same domain credentials, they get encrypted in the attack too. Keep at least one backup copy on immutable storage or in an environment separated from the network.
How to Set RPO and RTO
RPO and RTO are business decisions, not technical ones; the technical team shows what each target costs. RPO and RTO approaching zero means cost that grows steeply. That’s why each system needs its own targets:
| System class | Example | Typical RPO | Typical RTO |
|---|---|---|---|
| Critical | Payments, orders, production planning | Minutes or zero | Minutes – 1 hour |
| Important | ERP, CRM, accounting | 15 minutes – 1 hour | A few hours |
| Standard | Reporting, internal applications | 1 day | 1 working day |
| Archive | Historical data | 1 week | A few days |
These values are examples. When you set your own, ask: “What does it cost the business if this system is down for an hour, or if the last hour of data is lost?”
DR Options by Platform
| Platform | Option | RPO | Note |
|---|---|---|---|
| SQL Server | Asynchronous Always On replica at a remote site | Seconds | Enterprise edition; the failover decision and quorum design are critical |
| SQL Server | Log shipping | Minutes (log backup frequency) | Simple and robust; manual failover |
| SQL Server | Copying backups to another site or the cloud | Log backup frequency | Lowest cost; RTO depends on restore time |
| Oracle | Data Guard (physical standby) | Seconds or zero (depending on mode) | Enterprise Edition; Active Data Guard needs an extra license |
| Oracle | Copying RMAN backups and archive logs to another site | Archive log frequency | RTO depends on restore time |
| PostgreSQL | Streaming replica at a remote site | Seconds | Built in; a cluster manager or procedure for failover |
| PostgreSQL | pgBackRest repository on another site (with WAL archiving) | Seconds – minutes | Point-in-time recovery (PITR) |
We compare SQL Server’s high availability options in our HA guide, and cover the quorum mistake common in DR designs in our Always On posts. For PostgreSQL, see our high-availability setup post.
What a DR Plan Should Contain
| Section | Content |
|---|---|
| Scope and targets | Which systems, with RPO and RTO for each |
| Architecture | Primary and DR sites, replication and backup flows, dependencies (Active Directory, DNS, application servers) |
| Decision process | Who declares a disaster, and under what conditions you fail over to DR |
| Contact list | Technical team, business units, suppliers; phone numbers and backup communication channels |
| Step-by-step procedures | Failing over to DR, repointing applications, validation, failing back to the primary site |
| Credentials | Admin accounts kept in a secure vault that’s reachable during a disaster |
| Validation checks | Data consistency, tests of critical business workflows |
| Drill records | Date of the last test, measured times, gaps found |
Warning
Don’t keep the DR plan only where the primary system is reachable. Being unable to reach the plan itself, the credentials and the contact list during a disaster is a common failure that’s easy to prevent.
Drills: Prove the Plan Actually Works
| Test type | What happens | Frequency |
|---|---|---|
| Restore test | Critical databases are restored to a separate server and timed. | Monthly or quarterly |
| Tabletop exercise | The team walks through the plan step by step against a scenario. | Every six months |
| Partial DR test | One or a few systems are brought up and validated at the DR site. | Once or twice a year |
| Full DR drill | All critical systems run at the DR site as if the primary site were down. | Once a year |
Answer three questions after every drill: Did we meet the RTO target? How much data was lost? What did we have to do that wasn’t in the plan? The answers to the third question go into the next version of the plan.
Common Mistakes During a Disaster
The mistakes we see most often in the field aren’t technical; they’re decisions made in panic: restarting the system again and again, several people making different interventions at once, trying to restore the database to another server while recovery is still running. For a calm roadmap during an outage, see our first 30 minutes runbook and our RECOVERY PENDING and SUSPECT guide.
Regulated Sectors
In Turkish banking, the regulation on banks’ information systems and electronic banking services requires primary and secondary systems to be located in Türkiye, with enough in-country staff to ensure continuity. When choosing a DR site, especially with cloud-based solutions, always assess data residency requirements like these.
Disaster Recovery with Aryasoft
Aryasoft sets RPO and RTO targets for your databases together with your business units, builds the right DR architecture for SQL Server, Oracle and PostgreSQL, documents the backup and retention policy and the emergency action plan, and proves the plan with regular drills. For real recovery examples, see our stories on recovery with a 1-minute RPO, Always On recovery without data loss and zero-downtime data recovery for a payment services company. We cover the backup side in detail in our backup plan guide.
Frequently Asked Questions
Sources
The technical details in this guide were checked against the following sources in November 2026.
- Microsoft Learn: Business continuity and database recovery – SQL Server
- Microsoft Learn: About log shipping
- Oracle Data Guard Concepts and Administration
- PostgreSQL documentation: Continuous Archiving and Point-in-Time Recovery
- PostgreSQL documentation: Log-Shipping Standby Servers
- Regulation on Banks’ Information Systems and Electronic Banking Services (Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik), Turkish Official Gazette, 15 March 2020, No. 31069
Disaster Recovery
Prove your plan with drills
Aryasoft sets your RPO and RTO targets, builds the DR architecture, documents the plan and proves it with regular drills.
