Ask a sales director how long the CRM can be down and the answer is “not at all.” Ask what they would pay to guarantee that, and the answer changes. Disaster recovery planning is mostly the work of turning that first answer into numbers the business has actually agreed to, then building only as much resilience as those numbers justify.

Two numbers that drive everything

Recovery time objective (RTO) is how long the CRM can be unavailable before the damage becomes unacceptable. Recovery point objective (RPO) is how much recent data you can afford to lose, measured as time. An RPO of one hour means that after a recovery, you may lose up to the last hour of changes.

They are independent. A system can recover fast but lose a day of data, or recover slowly with nothing lost. Treat them as separate conversations.

A practical way to get honest answers is to ask concrete questions instead of abstract ones:

• If the CRM is down for a morning, what stops? Quotes? Support escalations? Renewals?
• If we lost this morning’s edits, could people re-enter them from email or memory?
• Which weekdays or month-end periods are worse than others?

You will often find that parts of the CRM matter more than others. Opportunity updates and case records may be urgent, while marketing campaign history can wait.

Failure types are not all the same

Plan for different scenarios separately, because the right response differs:

1. Component failure, such as one server or one availability zone. Usually handled by redundancy within a region.
2. Regional outage, where a whole location is unavailable. Needs a second region.
3. Bad deployment or data corruption, where the system is up but wrong. Redundancy copies the problem; only point-in-time recovery or backups help.
4. Accidental deletion or malicious change, a close relative of the third case.
5. Vendor or account-level problem, such as a locked account. Needs exports or copies held outside that account.

A frequent blind spot is the third case. Teams invest in replication to a second region and then discover that replication faithfully copied a bad bulk update within seconds. Replication is not a backup.

Three recovery approaches

Backup and restore. You keep regular backups, ideally in another location, and rebuild when needed. Cheapest to run, slowest to recover. The recovery time includes provisioning infrastructure, restoring data, reconnecting integrations and testing. Many teams underestimate it badly until they run a drill.

Warm standby. A scaled-down copy of the environment runs in a second location with data continuously replicated. On failure you scale it up and redirect traffic. Faster recovery, moderate cost, and more moving parts to keep in sync.

Active-active. Two or more locations serve traffic simultaneously. Recovery can be near-instant, but this is the most complex and costly design, and conflicts in writes need careful handling. Few CRM workloads genuinely need it.

If you use a fully managed CRM, much of this is the vendor’s responsibility. Read their current documentation and service terms for stated recovery targets, and then plan your side: exports, integration recovery and your own communication procedures.

Matching approach to need

Business tolerance	Typical approach	Main cost	Main risk
Can be down for a day or more, minimal data loss concern	Backup and restore	Low	Slow, untested rebuild
Can be down for a few hours, small data loss	Warm standby	Medium	Standby drifting out of date
Cannot be down more than minutes	Active-active or highly automated failover	High	Complexity and write conflicts
Corruption is the main fear	Point-in-time recovery plus tested backups	Low to medium	Slow detection of the problem

These are categories, not guarantees. Your platform’s real behaviour determines the actual numbers, so measure them.

What a recovery plan must include

Infrastructure is half the story. The plan also needs:

• A named person who can declare a disaster, so nobody waits for a committee.
• A step-by-step runbook that a tired person at 3 a.m. can follow.
• DNS and traffic redirection steps, with the lead time for changes to take effect.
• A list of integrations and what each needs after failover: new endpoints, new credentials, replayed messages.
• A communication template for staff and customers.
• A plan for returning to the primary site afterward, which people forget until they are stuck in the standby.

A hypothetical drill

A mid-sized company believes its CRM has a four-hour recovery time. During a test they restore from backup into a clean environment. The database restore takes less time than expected, but they spend two hours finding the configuration for the single sign-on connection, one more hour waiting for a firewall change request, and another discovering that the billing integration still points to the old address.

The real figure was closer to seven hours, and almost none of the delay was in copying data. Their fix was not a bigger standby; it was putting the configuration into version control, pre-approving the firewall rules, and adding an integration checklist to the runbook.

Frequently Asked Questions

Is a daily backup enough? It gives you an RPO of up to a day, so you could lose a full day of work. Whether that is acceptable depends on how easily users can recreate that data. Many teams add more frequent database snapshots or continuous point-in-time recovery.

Does replication replace backups? No. Replication copies whatever happens, including mistakes and deletions. Keep independent, versioned backups as well.

How often should we test disaster recovery? At least once a year for a full exercise, and after significant architecture changes. Smaller tests, such as restoring a single table, can run much more often.

Who sets the RTO and RPO? The business owners of the process, informed by technical cost estimates. Engineering proposes options with prices; the business chooses.

Do we need a second region for a CRM? Only if the cost of a regional outage justifies it. Many organisations are well served by multi-zone redundancy within one region plus strong, tested, off-site backups.

Next Step

Hold a thirty-minute meeting with one business owner and write down an RTO and RPO for the CRM’s three most important functions. Then schedule a restore drill to find out what your current setup actually delivers.