Disaster Recovery for Your Own Website: RTO/RPO Definitions, Recovery Steps, and Annual Drills

Disaster Recovery RTO/RPO Tiers and a Four-Step Annual Drill Process

Disaster Recovery for Your Own Website: RTO/RPO Definitions, Recovery Steps, and Annual Drills

Bottom line first: Disaster recovery rests on two core metrics: RTO (Recovery Time Objective) and RPO (Recovery Point Objective). For most B2B standalone sites, a reasonable RTO is 4 hours and RPO is 4 hours. You don’t need to chase 99.99% uptime—that’s an ecommerce and payments-level requirement, and the cost rises exponentially. The recovery process has four steps: switch traffic to the standby server, restore the database and files from backup, verify that inquiry forms and email delivery work, then switch back to the primary site. Run a drill at least once a year, time the whole thing, and if actual RTO/RPO exceeds the target, upgrade your plan.

1. RTO and RPO: First Figure Out How Much Data You Can Lose and How Long You Can Be Down

RTO (Recovery Time Objective) is the longest acceptable time from a site failure to restoring service to the outside world. RPO (Recovery Point Objective) is how much data loss you can tolerate after recovery. Once you set these two numbers, your backup frequency and disaster recovery investment are set too—they’re a trade-off between cost and uptime.

A counterintuitive call: for a B2B standalone site, chasing 99.99% uptime is overinvestment. B2B sites get little traffic and inquiries come mainly through email and forms, so being down 4 hours versus 1 hour makes little practical difference to the business—but the disaster recovery cost difference is huge. To hit an RTO of 15 minutes, you need dual active data centers and real-time database sync, and the monthly cost is 5 to 10 times that of a single data center setup.

Site type	RTO target	RPO target	Uptime	Disaster recovery plan
Core inquiry site	≤1 hour	≤15 minutes	99.9%	Remote standby server + real-time binlog sync
Standard B2B site	≤4 hours	≤4 hours	99.5%	Single data center + daily backup + remote recovery
Blog/content site	≤24 hours	≤24 hours	99%	Weekly backup + manual recovery
Ecommerce/payments site	≤15 minutes	≤1 minute	99.99%	Multi-active + real-time sync (extremely costly)

Example: an industrial equipment exporter’s site gets about 30 inquiries a month with an average order value of 500,000 RMB. If the site is down 4 hours, based on inquiry density you’d miss roughly 1 to 2 inquiries—a limited loss. A single data center plus daily backups, with RTO 4 hours and RPO 4 hours, is enough, and the monthly disaster recovery cost is under 200 RMB. If you force dual active, the extra 2,000 RMB a month buys uptime with no measurable return for the business.

To judge which category your site falls into, look first at monthly inquiries and average order value: over 100 inquiries a month with an average order value under 10,000 RMB leans ecommerce, so RTO should be pushed down to 1 hour; under 30 inquiries a month with an average order value over 100,000 RMB leans project-based, and an RTO of 4 hours is perfectly acceptable.

2. The Recovery Process: Four Steps, Written Down in Advance

A disaster recovery plan can’t just live in your head. When an incident hits, the person on call might be woken up at 3 a.m., might be traveling, or might not be the one who knows the system best. The plan has to be written down, with steps detailed down to the command line, so it’s crystal clear who does what and when.

The standard recovery process has four steps: Step one, switch traffic — point DNS or CDN to the backup server IP. Step two, restore data — pull the latest backup from offsite object storage and restore files and databases. Step three, verify — walk through the homepage, product listings, inquiry form submission, and email delivery. Step four, notify stakeholders — sync the recovery time with sales, support, and management. For the special recovery process after a hack, see After your site gets hacked.

Steps	Action	Department head	Estimated time	Acceptance Criteria
1. Confirm the incident	Monitoring alert fires, confirming the main site is down	On-call ops	5 minutes	3 consecutive probe failures
2. Switch traffic	Lower DNS TTL to 60 seconds, switch to backup server IP	Operations	10 minutes	Global DNS propagation
3. Restore data	Pull backup from S3, restore files and databases	Operations	1 to 2 hours	Site is accessible
4. Verify functionality	Walk through homepage, product pages, and inquiry form	Ops + sales	30 minutes	Form submission email received
5. Notify	Sales and support know the site is back up	Marketing lead	10 minutes	Notification posted in the group chat
6 Review	Write incident report within 24 hours	Technical lead	1 business day	Root cause and improvements

Example scenario: An overseas site alerts at 3 a.m., main site returns 502. The on-call ops follows the plan: Step one, confirm it’s a MySQL crash, restart doesn’t help; step two, switch DNS to the backup server — TTL was already set to 60 seconds, so it propagates globally in 10 minutes; step three, pull last night’s backup from S3 and restore the database, done in 40 minutes; step four, submit a test inquiry from a phone, email arrives 30 seconds later; step five, notify sales in the group chat — by the time they start at 8 a.m., the site is back to normal. Total RTO is about 1 hour, RPO about 6 hours, meeting the plan’s targets.

For details on coordinating DNS switching with CDN, see CDN global acceleration for node failover. Changing domains and 301 handover follow a similar approach, see Site rebuilds and domain changes.

3. Backup and cold standby: you don’t always need active-active

Disaster recovery comes in three tiers: cold standby, warm standby, and active-active. Cold standby means you only have backup files and spin up a machine to restore when something happens; warm standby means the backup server is always running idle with asynchronous data sync; active-active means two data centers handle traffic simultaneously with real-time sync. Cost goes from low to high, RTO from long to short.

Most B2B standalone sites do fine with a mix of cold and warm standby: the backup server stays on but doesn’t take traffic, syncs data once a day, and when something happens you just change DNS to switch over — RTO can be kept to 1–2 hours. Active-active is overkill for a solo operator or small team; the operational complexity is more than you can maintain.

Solution	Backup server status	RTO	Monthly cost increase	Best for
Cold standby	No backup server, only backups	4 to 8 hours	Free	Blogs, content sites
Warm standby	Backup server always on, daily sync	1 to 2 hours	About 300–500 yuan	Mainstream B2B inquiry sites
Hot standby	Backup server always on, real-time sync	15 to 30 minutes	About 1,500–3,000 yuan	Core business sites
Active-active	Serving both regions at once	Seconds	About $700+	Ecommerce, payments

Counterintuitive warning: DNS changes are not instant. Even with a 60-second TTL, global DNS propagation takes 5 to 15 minutes, and some users’ local DNS caches will hold onto the old address for hours. So before you shift traffic, set your expectations: once you switch, not everyone will hit the standby server right away. There will be a transition period. Your runbook should state plainly: “After the DNS switch, wait 15 minutes before verifying global access.”

4. Annual drill: run the plan and find the gaps on paper

The biggest risk with a disaster recovery plan is treating “written” as “done.” The document looks flawless, but when a real incident hits, you find out nobody knows the standby server password, the backup files won’t download, and the SMTP config is hardcoded on the old server. These problems only surface when you actually run a drill.

Schedule the annual drill for early Sunday morning during your low-traffic window, and time the whole thing. The drill doesn’t mean actually cutting traffic away from the primary site. Instead, walk through the full recovery process in a test environment, from pulling the backup to verifying the form, and record how long each step actually takes. Compare the real RTO against your target, and if you exceed it, upgrade the plan. After the drill, write a retrospective and update the runbook.

Drill item	What to check	FAQ	Improvement
Backup availability	Can the latest backup be pulled from S3 and extracted?	Corrupted gzip, expired keys	Add backup integrity checks
Standby server startup	Can the standby server come up within 5 minutes?	Standby server hasn’t been booted in ages, software is outdated	Boot the standby server once a month
DNS switch	Is the TTL really 60 seconds?	Forgot to lower the TTL in advance	Set TTL to 60 seconds permanently
Database recovery	Does Chinese text display correctly after import?	Wrong character set, garbled text	Fix the character set in the recovery script
Form email	Does a test inquiry come through after submission?	SMTP password hardcoded in the old config	Use environment variables for SMTP
Staff readiness	Can you reach the on-call person?	No handover when someone left	Update contacts every quarter

Example scenario: a team runs its first annual drill. They follow the plan to pull the backup, restore the database, and access the site. The first 40 minutes go smoothly. Then they get to verifying the inquiry form, and after submitting, no email arrives for ages. It turns out the SMTP password was written into wp-config.php, and the old server’s mail service was shut down long ago. If this had surfaced during a real incident, it would have cost another hour of troubleshooting. That’s the value of a drill: catching this kind of paper problem ahead of time.

For detailed backup configuration, see Backup and recovery drills for your site. For monitoring alert thresholds, see Site monitoring and alerts. For the routine maintenance checklist, see Six Monthly Tasks for Site Maintenance.

FAQ

What exactly are RTO and RPO, and how do you set them?

RTO is the recovery time objective: the longest acceptable time from failure to service restoration. RPO is the recovery point objective: how much data loss, measured in time, you can tolerate after recovery. For a B2B standalone site, RTO 4 hours and RPO 4 hours is the recommended setup, and it is enough for project-based businesses with around 30 inquiries a month and high order values. If you get more than 100 inquiries a month, the site leans e-commerce, so tighten RTO to 1 hour. The shorter you set RTO, the more costs rise exponentially, so don’t chase 99.99% availability blindly.

Does a B2B standalone site need active-active?

In most cases, no. Active-active means two data centers serving traffic at the same time with real-time database sync. It costs over 5,000 yuan a month, and the operational complexity is a disaster for one person or a small team. A warm standby is more cost-effective: the standby server stays on but takes no traffic, syncs data once a day, and when something goes wrong you change DNS and switch over. That keeps RTO to 1-2 hours for an extra 300-500 yuan a month. Only sites with e-commerce, payments, or several hundred inquiries a month should consider hot standby or active-active.

How detailed should a disaster recovery plan be?

Write it down to the command-line level. Include: failure criteria (three consecutive failed probes count as an incident), the exact steps and wait times for switching DNS, which backup to pull from which S3 bucket, the full commands to restore the database, a verification checklist (homepage, product pages, inquiry form, email delivery), a contact list with phone numbers, and a post-mortem report template. Don’t write vague things like “contact ops” — spell out specific names and backup contacts. Store the plan in both a password manager and cloud storage, not only on the server that goes down.

How do we run the annual drill, and do we need to take the site offline?

Run it in a test environment; don’t actually take the main site down. The process: pull a recent backup into the test environment and walk through the full recovery flow, from unzipping files, importing the database, configuring nginx, accessing the site, and submitting a test inquiry to receiving the email, timing the whole thing. Compare the actual time against the plan’s RTO target, and upgrade the plan if you exceed it. Schedule the drill for early Sunday morning during the low-traffic window, at least once a year, and new hires must take part in one within six months of joining.

How long does a DNS switch take, and why are users still hitting the old site after the switch?

Even with TTL set to 60 seconds, global DNS propagation takes 5 to 15 minutes, and some users’ local DNS caches will hold the old address for hours. That’s normal, not a configuration failure. Before switching traffic, lower TTL to 60 seconds in advance (ideally keep it at 60 seconds all the time, rather than lowering it only when something goes wrong). After the switch, wait 15 minutes before verifying global access, and notify sales and support that some users may still be hitting the old site during the transition.

Is the recovery process the same for a hack and a hardware failure?

No. With a hardware failure, you just restore from backup to the standby machine. A hack takes two extra steps: first, you can’t just restore the old backup, because it may already contain a backdoor; second, after restoring you must change every password and key, check cron jobs and the database for webshells, and only put the site back online once you’ve confirmed it’s clean. For the full process, see After your site gets hacked article. Confusing these two types of recovery is a common mistake: after a hack, you restore the old backup directly and end up restoring the backdoor along with it.

Final thoughts

The most dangerous mindset in disaster recovery is “we have backups, so we’re fine.” Backups keep your data from being lost; disaster recovery is about how fast you can get service back after something goes wrong, who does it, and how. The two are separated by an entire set of plans and drills. Backups without a plan still leave you scrambling when something happens; a plan without drills still stalls when you actually need it.

Three steps to make it real: first, set your RTO/RPO based on monthly inquiry volume and average order value. For most B2B sites, 4 hours is enough, so don’t chase a higher number for its own sake. Second, write a recovery plan down to the command-line level and store it in two places: your password manager and your cloud drive. Third, run a full drill in a test environment once a year, record your actual RTO/RPO, and upgrade the plan if you miss your targets. Once these three steps are done, you’ll know exactly how long your site would take to come back after something goes wrong.

One line worth remembering: higher RTO isn’t always better. Going from 4 hours to 15 minutes costs 10 times as much. First work out exactly how much 4 hours of downtime would cost you, then decide how much disaster preparedness you actually need.