Description
What is disaster recovery (DR)?
Disaster recovery (DR) is the set of plans, backups, infrastructure and drills that let an organisation restore its systems and data after a major loss — a cloud region going down, a database corrupted or deleted, ransomware, or a compromised account. It is broader than Failover, which switches traffic automatically to a standby that is already running: DR covers the cases where no healthy standby exists, and the people, runbooks and decisions needed to rebuild, usually coordinated through your Incident Management process. It is unrelated to RTO (Return to Origin), the e-commerce term for parcels sent back to the seller.
Two targets frame every DR plan. The recovery point objective (RPO) is the maximum acceptable data loss, measured in time: an RPO of 5 minutes means losing at most the last 5 minutes of writes, which needs continuous replication or log shipping rather than nightly backups. The recovery time objective (RTO) is the maximum acceptable time to restore service. Common strategies trade cost against these targets: backup and restore (cheapest, hours), pilot light (core data replicated, minutes to hours), warm standby (a scaled-down copy running, minutes) and multi-site active-active (near zero, most expensive). High Availability keeps you running through small failures; DR is for the large ones.
For a WhatsApp integration, Meta runs the Cloud API itself — and since the On-Premises API was sunset on 23 October 2025 there is no WhatsApp client of your own to fail over — so DR is about your side: the webhook receiver, the queues, the database of conversations, opt-ins and message statuses, downloaded media, and the access tokens and app secret. Meta's Webhook Retry Policy buys time but is not a backup: undelivered webhooks are retried for up to seven days, media IDs received in webhooks expire after seven days, and Meta keeps message data for at most 30 days.
Key takeaways
- Disaster recovery restores service and data after losing a whole region, data store or account — not just a single server.
- RPO is how much data you can afford to lose, measured in time; RTO is how long you can afford to be down.
- A backup you have never restored is a hope, not a plan: run restore drills and measure the RPO and RTO you actually achieve.
- Meta hosts the WhatsApp Cloud API, but your webhook receiver, database, queues and tokens are yours to recover.
- Meta retries webhooks for up to 7 days and keeps message data for at most 30, so it is no substitute for your own backups.
Why it matters
Why does disaster recovery (DR) matter?
A DR plan decides whether a regional outage or a mistaken DROP TABLE costs an hour or a month. For a messaging business the losses are specific: opt-in records you are expected to keep, conversation history agents need, delivery statuses that billing reconciles against, and personal data protected under the Digital Personal Data Protection Act. Customers and regulators judge you on how fast and how completely you recover — and the only way to know your real RPO and RTO is to rehearse them.
Properties
Disaster recovery (DR): key facts and limits
- RPO
- Maximum acceptable data loss, measured in time
- RTO
- Maximum acceptable time to restore service
- Strategies, cheapest first
- Backup and restore → pilot light → warm standby → active-active
- Meta webhook retries
- Up to 7 days, at decreasing frequency
- Media IDs from webhooks
- Expire after 7 days
- Meta message data retention
- At most 30 days
- On-Premises API
- Sunset 23 October 2025; Cloud API only
Mechanics
How does disaster recovery (DR) work?
step 1 — Set RPO and RTO per system
Rank data stores and services by business impact: opt-ins and conversations may need an RPO of minutes, analytics a day. Agree the targets with the business, not just engineering.
step 2 — Back up and replicate to match
Use point-in-time recovery or continuous replication for tight RPOs and automated backups for the rest, copied to another region and another account, with at least one copy that production credentials cannot delete.
step 3 — Make infrastructure and secrets rebuildable
Keep clusters, queues and DNS as infrastructure code, and replicate secrets — the system user access token, app secret and webhook verify token — to the recovery region, so nothing depends on the lost region's vault.
step 4 — Plan webhook continuity
Register a callback URL on a hostname you control, so DNS or a global load balancer can move it to the recovery region. A Webhook Override can move message-type events such as
messages, but template and account webhooks always go to the app's default URL.step 5 — Drill and measure
Restore the latest backup into a clean environment on a schedule, replay sample traffic, time every step and compare the achieved RPO and RTO with the targets. Update the runbook after each drill.
Usage
Disaster recovery (DR) in code
#!/usr/bin/env bash# Quarterly restore drill: restore the newest backup into a scratch database,# measure how old its newest data is (the RPO you would get) and time the restore.set -euo pipefailSTART=$(date +%s)LATEST=$(ls -1t /backups/wa-core/*.dump | head -n1)createdb wa_core_drillpg_restore --no-owner --jobs=4 --dbname=wa_core_drill "$LATEST"# Newest status in the restored copy vs now = data a real restore would losepsql -d wa_core_drill -Atc "SELECT now() - max(received_at) AS achieved_rpo FROM message_statuses;"psql -d wa_core_drill -Atc "SELECT count(*) FROM opt_ins;" # compare with productionecho "Restore took $(( $(date +%s) - START ))s of the RTO budget"dropdb wa_core_drill
A drill that produces numbers — achieved RPO and restore time — rather than a ticked box.
Caveats
Common mistakes with disaster recovery (DR)
Never restoring a backup
Backups fail silently: wrong schedule, missing tables, unreadable archives, a restore that takes ten times longer than assumed. Only a timed restore drill tells you your real RPO and RTO.
Backups inside the blast radius
Copies in the same region or the same cloud account disappear with a regional outage or a compromised admin credential. Keep at least one copy in another region and account, protected from deletion.
Forgetting secrets and configuration
A perfect database restore is useless if the access token, app secret or verify token lived only in the lost region. Replicate secrets and keep configuration in code.
Treating Meta as your backup
Meta processes Cloud API messages as a data processor and keeps message data for at most 30 days; it is not an archive of your conversations. Opt-ins, history and statuses must live in your own backed-up store.
Ignoring data residency in the recovery region
Restoring customer data to a region or country your contracts or policies do not allow turns an outage into a compliance problem. Choose recovery regions with your Data Residency commitments in mind.
Example
Example: A region drill at a Mumbai lending app
A lending app in Mumbai runs its WhatsApp stack in one cloud region with an RPO of 5 minutes and an RTO of 2 hours. In a quarterly drill the team simulates losing that region: they promote the cross-region database replica (achieved RPO: 40 seconds), deploy the stack from infrastructure code and repoint the webhook hostname's DNS. Meta's retries deliver the webhooks that queued during the switch, and the handler's dedupe table absorbs the duplicates. The drill takes 3 hours 10 minutes — over target — because the app secret lived only in the primary region's vault. With secrets replicated, the next drill finishes in 85 minutes.
Notes
Best practices for disaster recovery (DR)
- Write the RPO and RTO beside each data store on the architecture diagram, so gaps show up in design reviews.
- Time-box drills and treat overruns as findings, not failures.
- Keep the runbook somewhere that survives the disaster — a second system, or on paper.
- Rehearse the smaller disasters too: a deleted table or a leaked token happens far more often than a lost region.
Questions
DR FAQs
- What is the difference between RPO and RTO?
- RPO is how much data you can afford to lose; RTO is how long you can afford to be down. An RPO of 5 minutes and an RTO of 2 hours means losing at most 5 minutes of writes and being back within 2 hours.
- What is the difference between disaster recovery and failover?
- Failover automatically switches traffic to a standby that is already running; disaster recovery is the broader plan for when that is not enough. DR includes backups, rebuilding infrastructure, restoring data and the people and runbooks that coordinate it.
- Do I need disaster recovery if Meta hosts the WhatsApp Cloud API?
- Yes. Meta runs the API, but your webhook receiver, database, queues, media copies and tokens are yours to protect. Meta's retries cover up to seven days of webhook downtime, but it keeps message data for at most 30 days and is not your backup.
- How often should a disaster recovery plan be tested?
- Run restore tests of critical data stores at least quarterly and a full drill at least once or twice a year. Test again after major architecture changes, and record the achieved RPO and RTO every time.
- Does RTO mean the same thing in e-commerce?
- No. In e-commerce RTO usually means return to origin — a parcel sent back to the seller — not recovery time objective. The two only share an acronym; check which one a document means before acting on it.