Hardware fails, data centres have outages, people delete the wrong folder, and ransomware happens. A disaster recovery plan decides in advance how much data you can lose, how long you can be down, and the exact steps to get back. This guide covers the essentials with RPO and RTO.
Before you start
- An inventory of your services: websites, databases, email, DNS, and who depends on them.
- Background: website backups explained and uptime and SLAs.
RPO and RTO
- RPO (Recovery Point Objective): the maximum data loss you accept, measured in time. Daily backups mean an RPO of up to 24 hours.
- RTO (Recovery Time Objective): how quickly service must be back. Restoring a large server from off-site backup might take hours.
Set them per service; a shop's orders database deserves tighter targets than a brochure site.
Strategies from cheapest to fastest
| Strategy | Typical RPO | Typical RTO |
|---|---|---|
| Off-site backups, restore to new server | Hours to a day | Hours |
| Frequent backups + scripted rebuild (cloud-init/Ansible) | Minutes to hours | Under an hour |
| Warm standby with replication | Seconds to minutes | Minutes |
| Active-active across sites | Near zero | Near zero |
Higher tiers cost more and add complexity. Many small businesses are well served by good off-site backups and a tested restore process.
Building blocks
- Backups: follow 3-2-1 with at least one immutable or offline copy; see rclone to S3.
- Infrastructure as code: rebuild servers quickly with Ansible or cloud-init.
- Replication: database replicas and file sync to a second location.
- Failover: DNS failover or floating IPs.
Write a runbook
- Who declares a disaster and who does what (with contact details stored outside the affected systems).
- Where backups and credentials are, and how to access them if your main systems are down.
- Step-by-step restore order: DNS, database, application, email.
- How to verify the restored service and communicate with customers.
Test it
- Restore a backup to a fresh server at least a few times a year and time it against your RTO.
- Check that restored data is as recent as your RPO.
- Update the runbook after every test or incident.
Frequently asked questions
Are my host's backups enough?
They are a strong first layer (MdmHost hosting includes daily JetBackup backups), but keep your own off-site copy of critical data as well.
Is RAID a backup?
No. RAID protects against disk failure, not deletion, corruption or ransomware; see RAID levels.
How often should I back up?
Often enough to meet your RPO: daily for most sites, more often for busy databases.