Ask an infrastructure team how often the CRM is backed up and you will get an answer in hours. Ask the sales director how much recent work they can afford to lose and you will get a very different kind of answer, usually delivered with some alarm. RPO and RTO are the vocabulary that connects those two conversations. They look like jargon, but they are really two questions about pain.

The Two Questions

Recovery point objective (RPO) asks: how much recent data can we lose? If the system fails at 3:00 pm and your RPO is one hour, you are saying the business can accept losing up to an hour of changes, so a recovery to the state at 2:00 pm is acceptable. It is measured backwards from the failure.

Recovery time objective (RTO) asks: how long can the CRM be unavailable? If the RTO is four hours, then from the moment of failure to the moment people can work again should not exceed four hours.

They are independent. A system can have a tight RPO and a loose RTO (we cannot lose data, but we can wait a day) or the opposite. Mixing them up is the most common error, and it leads to buying the wrong protection.

Why They Drive Real Decisions

These two numbers translate directly into design and cost.

A long RPO can be met with nightly backups. A short one needs more frequent copies, or continuous capture of database changes, or a replica that stays nearly in sync. Each step down costs more in storage, bandwidth and operational care.

A long RTO allows restoring from backup onto freshly built infrastructure. A short RTO needs standby systems that are already built and warm, plus rehearsed procedures, because restoring a large database from backup takes time you can measure but cannot compress by wishing.

So choosing RPO and RTO is really choosing how much to spend. That is why they must be set with the business rather than by the infrastructure team alone.

Get the Business to Answer Honestly

People tend to answer “zero” to both questions, because nobody wants to say that losing data is acceptable. The trick is to make the trade-off concrete. Ask scenario questions:

• If we lost the last hour of updates, what would people have to redo, and how much would that cost or annoy?
• If the CRM were down for half a day during a busy sales period, what would stop?
• Are there times of year when downtime is far worse, such as quarter end?
• Which functions matter most? Perhaps order-related data must be protected tightly while marketing history can wait.

Then show the price of each tier. When the director sees that near-zero data loss requires a notably more complex setup than a few hours of tolerance, the answers become realistic. Record them, get them signed off, and revisit them annually.

It also helps to set objectives per component rather than one for the whole stack. Core records, attachments, integration queues and reporting copies often deserve different targets.

Check That Reality Matches the Promise

An objective is only a wish until you verify it. Compare the target with what your setup can actually achieve:

• Actual RPO equals the gap between your most recent usable backup or replicated state and the moment of failure. If backups run nightly but take hours and sometimes fail, the real figure may be worse than a day.
• Actual RTO is the sum of everything: noticing the problem, deciding to recover, provisioning or switching systems, restoring data, validating, repointing users. Only a timed drill reveals it. Teams routinely discover that the restore itself is a small part and that decision-making and access problems dominate.

Where reality falls short of the target, you have three choices: spend more, relax the target with the business agreeing, or improve the process. All of them are better than discovering the gap during an outage.

Mapping Objectives to Approaches

Business tolerance	Typical approach	Main cost or complexity
Can lose a day, can wait a day or more	Nightly full backup, restore to rebuilt infrastructure	Lowest cost, slow recovery
Can lose hours, can wait hours	Frequent incremental backups, scripted rebuild	Moderate effort, tested scripts needed
Can lose minutes, can wait an hour or so	Continuous log shipping or replication, warm standby	More infrastructure and monitoring
Cannot lose data, minimal downtime	Synchronous replication, automated failover	Highest cost and complexity, rigorous testing

The approaches are generic illustrations. Exact capabilities depend on your database engine, hosting model and CRM, so check the relevant vendor documentation.

A Hypothetical Example

Imagine a company where the infrastructure team has set nightly backups and assumes that is fine. In a conversation with the sales leadership, they learn that sales staff log calls and update opportunities throughout the day and would struggle to reconstruct a day’s notes from memory. Staff estimate they could tolerate losing about an hour of work, and could manage without the CRM for a few hours using shared spreadsheets, though not a whole day.

That points to an RPO of roughly an hour and an RTO of a few hours. The nightly schedule clearly misses the first target. The team adds frequent transaction log backups, then runs a timed restore drill and finds the restore takes longer than expected because of a slow copy from remote storage. They adjust the storage location and update the runbook. The numbers are now achievable and have been measured, not assumed.

Write Them Down Where People Will Find Them

Keep the agreed objectives in your disaster recovery documentation along with the date, the approver and the test results. Review them whenever something material changes, such as growth in data volume, a new business-critical integration, or a move between hosting models. A target agreed when the database was small may be unreachable now.

Frequently Asked Questions

Is RPO the same as backup frequency? Not quite. Backup frequency influences your achievable RPO, but the real figure also depends on backup success, replication lag and how current the restorable state is at the moment of failure.

Can RTO be shorter than the time to restore the database? Only with a design that avoids a full restore, such as a warm standby or replica that can be promoted. Otherwise the restore duration sets a floor on recovery time.

Who should sign off on the objectives? A business owner who understands the operational impact, with the infrastructure team advising on feasibility and cost. Infrastructure staff should not decide tolerance for data loss alone.

Should every part of the CRM have the same targets? Not necessarily. Different data and functions have different importance, and tiered objectives can save money while protecting what matters most.

How do we know our numbers are real? Test. Run a timed restore or failover drill, record how long each stage took and how much data was missing, and compare the results with the agreed targets.

Next Step

Schedule a thirty-minute conversation with one business owner and ask the two questions in plain words: how much recent work could you afford to redo, and how long could you manage without the system? Write down the answers and compare them with what your current backups would deliver.