Business Continuity for ERP: RTO, RPO, and What Fails First

At 2:40 a.m. on a Tuesday, a regional food distributor's primary database server lost a RAID array. The company had backups, dutifully run every night, but nobody had tested a full restore in over a year. It took the IT team 14 hours to get production ERP back online, not because the backup was bad, but because the documented restore procedure referenced a server configuration that had changed eighteen months earlier and nobody had updated the runbook. Order entry, warehouse picking, and invoicing all ran on paper and memory for most of a business day, and the company spent the following two weeks re-entering data and chasing down orders that had been taken by phone and never properly recorded.

That's what business continuity planning for ERP is actually about, not whether backups exist, but whether the organization can prove, before an incident, that it can restore operations within a time frame the business can survive. Two numbers drive that entire conversation: RTO and RPO. Most firms that get burned the way the distributor did aren't missing a disaster recovery plan on paper, they're missing a tested one.

RTO and RPO: the two numbers that actually matter

Recovery Time Objective is how long the business can tolerate the system being down before the damage becomes unacceptable. Recovery Point Objective is how much data the business can tolerate losing, measured in time, the gap between the last good backup and the moment of failure. A company that backs up nightly at midnight and suffers a failure at 4 p.m. the next day has, by definition, a 16-hour RPO: everything entered since midnight is gone unless there's a more frequent backup or transaction log in place.

These aren't abstract targets, they need to be set deliberately based on what the business actually loses per hour of downtime and per hour of lost data. A distributor processing $60,000 a day in orders through an 8-hour operating window is losing roughly $7,500 an hour of unrecoverable throughput during downtime, which makes a 14-hour recovery a very different number than a 2-hour one, and makes the case for investing in faster recovery capability concrete rather than hypothetical.

What actually fails first

The database server, predictably

Hardware failure, whether a RAID controller, a failed drive, or a full server loss, remains the most common single point of failure for on-premises ERP, and it's also the most straightforward to plan for: redundant hardware and tested failover reduce this risk to a manageable level for a known, bounded cost.

Network and connectivity, less predictably

A cloud-hosted ERP is only as available as the internet connection reaching it. A distribution warehouse with a single ISP circuit and no failover connection is one fiber cut away from being unable to reach an otherwise perfectly healthy cloud system. This risk gets overlooked because it isn't the ERP vendor's problem to solve, it's the customer's own network resilience, and it rarely gets budgeted the same way server redundancy does.

The backup itself, most dangerously

The distributor's actual failure wasn't the RAID array, RAID arrays fail regularly and are a known, planned-for risk. The real failure was a restore procedure nobody had verified worked. A backup that completes without an error is not the same thing as a backup that can actually be restored within the target RTO, and the gap between those two things is exactly where most business continuity plans quietly fail, because "the backup ran successfully last night" feels like enough reassurance that nobody schedules the more uncomfortable test of actually restoring from it.

People, especially the one person who knows the system

A continuity plan that depends on a single IT staffer's specific knowledge of the restore procedure is a plan with a single point of failure that has nothing to do with hardware. If that person is unreachable, on vacation, or has left the company, the documented runbook needs to be complete enough that someone else can execute it under pressure, not a set of notes that only make sense to the person who wrote them.

Cloud ERP doesn't eliminate the continuity question, it relocates it

A common assumption is that moving to cloud-hosted ERP outsources business continuity entirely to the vendor. That's only partly true. A reputable cloud ERP vendor typically handles infrastructure redundancy, database backups, and data-center-level disaster recovery competently, often better than a mid-size company could build in-house. What the vendor's SLA does not cover is the customer's own dependencies: the internet connection reaching the vendor, the customer's own integrations and middleware that might not fail over as cleanly as the core ERP does, and the customer's own procedural readiness, does staff know what to do operationally during an outage, whoever's fault it is.

A distributor with cloud ERP still needs an answer for "what does the warehouse do for the two hours the vendor's status page shows an outage." That's a business continuity question the vendor's own redundancy doesn't solve, because it's about the customer's operational fallback, not the vendor's infrastructure at all. Reading the vendor's published SLA carefully, specifically its stated RTO/RPO commitments and what's excluded, is the first step; building an internal fallback procedure for the gap that remains is the second, and it's the step companies skip most often because it feels like the vendor's problem once the contract is signed.

Building a plan that survives contact with an actual incident

• Set RTO and RPO based on real cost-of-downtime numbers, not a generic target copied from a template. Run the actual figures through a downtime cost calculator to see what an hour of outage genuinely costs before deciding how much redundancy is worth paying for.
• Test a full restore at least twice a year, on a schedule, not "when there's time." A restore test that isn't scheduled reliably doesn't happen.
• Keep the runbook current after every infrastructure change, and assign explicit ownership for updating it, not an implicit assumption that whoever made the change will remember to document it.
• Plan for network failure separately from server failure if any part of the ERP is cloud-hosted; a secondary internet connection is cheap insurance against a single point of failure that has nothing to do with the ERP vendor.
• Cross-train at least two people on the actual restore procedure, so the plan doesn't depend on one person's availability during an incident.

What changed after the outage

The distributor's actual fix cost less than the outage did. They moved to a documented quarterly restore test, cross-trained a second IT staffer on the full recovery procedure, and added a secondary internet circuit at the warehouse for about $340 a month. None of it eliminated risk entirely, disasters still happen, but the next hardware failure, a failed drive on a different server eight months later, took 90 minutes to recover from instead of 14 hours, because this time the restore procedure had actually been tested in the two months prior and the person executing it wasn't doing it for the first time under pressure.

The total spend on those fixes, roughly $9,000 in consultant time to rebuild and test the runbook plus the ongoing monthly circuit cost, was a fraction of what a single 14-hour outage had already cost the business once lost throughput, overtime for the manual re-entry catch-up, and a handful of strained customer relationships were counted. That's usually how the business case for continuity planning actually gets made inside a company: not by estimating hypothetical risk in the abstract, but by pointing at the invoice from the last time it went wrong.