A client's finance director once told me their DR requirement was "zero data loss, back up within minutes," in the same sentence as their approved infrastructure budget, and the two were not compatible. Most DR conversations for Acumatica go sideways early because RTO and RPO get treated as one number - "how fast can we recover" - when they're actually two independent numbers with different costs attached, and nobody in the room has separately priced out each one before making a promise.
Two different questions, two different bills
RPO (Recovery Point Objective) answers "how much data can we afford to lose," measured backward in time from the failure. An RPO of 15 minutes means you can tolerate losing the last 15 minutes of transactions - the orders entered, invoices posted, payments applied since the last successful replication point. RTO (Recovery Time Objective) answers "how long can the business run without the system," measured forward from the failure to full restoration. An RTO of 4 hours means the business can survive Acumatica being unavailable for 4 hours before real damage accumulates.
These pull on completely different levers. RPO is a function of how frequently and how continuously you're replicating data - log shipping interval, Always On Availability Group synchronous vs asynchronous commit, snapshot frequency. RTO is a function of how much manual work and infrastructure provisioning stands between "the primary is down" and "users are back in the system" - whether a standby is warm and waiting or has to be built from scratch, whether DNS/traffic routing failover is automated or requires someone to update records by hand at 2am.
I've seen clients invest heavily in SQL Server Always On synchronous commit - genuinely excellent, near-zero RPO - while their failover process for the web tier was still "someone remote-desktops into the standby server and manually starts IIS," turning a sub-minute RPO into a multi-hour RTO because the data was safe but nothing was actually serving traffic. Price and design these as two separate requirements, because a client who says "zero data loss" is answering the RPO question and hasn't necessarily thought about the RTO question at all.
What actually drives RPO for an Acumatica deployment
Because virtually all of Acumatica's state lives in SQL Server - PXCache is in-memory and transient, but everything it persists lands in the database - RPO for an Acumatica DR plan is almost entirely a SQL Server replication design question, not an application-tier question. The realistic options, in increasing order of cost and decreasing order of RPO:
- Nightly full backup + log backups every 15-30 minutes. RPO measured in tens of minutes at best; acceptable for smaller businesses where a DR event is rare and the finance team can reconstruct a short gap from source documents.
- Log shipping to a warm standby, asynchronous. RPO in the low minutes, modest infrastructure cost, standby lags primary by the shipping interval.
- Always On Availability Group, asynchronous commit to a secondary replica. RPO in seconds under normal load, but asynchronous commit means the primary doesn't wait for the secondary to confirm, so a hard failure at the wrong instant can still lose the last few transactions.
- Always On Availability Group, synchronous commit. Effectively zero RPO, because the primary's transaction doesn't commit until the secondary confirms it - at the cost of added write latency on every transaction and typically requiring the secondary to be close enough geographically that the latency hit is tolerable, which constrains how far apart your DR site can physically be.
What actually drives RTO for an Acumatica deployment
RTO is where the application tier - not just the database - determines the real number, and it's where I see clients most consistently under-invest relative to what they've spent on RPO. A synchronously-replicated database sitting behind a web tier that has to be provisioned from scratch after a failure adds hours to your RTO regardless of how good your RPO is. The levers that actually move RTO:
- Warm standby web/app tier vs cold provisioning. A pre-provisioned, patched, code-deployed standby web tier that's simply pointed at the failed-over database cuts RTO from hours to minutes. A standby that has to be spun up, patched, and have the current customization package deployed to it before it can serve traffic adds all of that time to your RTO, every time.
- Automated failover and traffic routing. DNS TTL and propagation delay, or better, an automated traffic manager / load balancer health check that redirects automatically, versus a human manually updating DNS records under stress at an inconvenient hour.
- Customization package parity. The standby environment must be running the exact same customization package version as production at all times, not "whatever was deployed last time someone remembered to sync it." A DR failover that surfaces a six-month-old customization build is a second incident stacked on top of the first.
RPO target SQL Server design
------------------------------------------------------------
Tens of minutes Full + frequent log backups, restore on demand
Low minutes Log shipping to warm standby (async)
Seconds Always On AG, asynchronous commit
Near-zero Always On AG, synchronous commit (latency cost)
RTO target Web/app tier design
------------------------------------------------------------
Many hours Cold: provision, patch, deploy on failure
1-2 hours Warm: pre-provisioned, deploy latest package on failure
Minutes Hot: standby running current package, automated failover
Getting the number right before quoting the infrastructure
I now insist on separate, explicit numbers for RTO and RPO before designing anything, and I push back hard on "as close to zero as possible for both" until the client has seen what that combination actually costs - synchronous AG replication plus a hot standby app tier with automated failover is a real, ongoing infrastructure spend, not a checkbox. Most businesses, once they see the honest cost, land on something like a 15-30 minute RPO and a 1-2 hour RTO, which is achievable with async log shipping or async AG plus a warm (not hot) standby, at a fraction of the cost of the zero/zero target nobody actually needed once they saw the bill.
Wrapping up
RTO and RPO are two separate requirements with two separate cost curves, and treating them as one "how fast can we recover" number is how DR budgets get misallocated - usually toward an impressively tight RPO sitting in front of a slow, manual RTO nobody priced properly. Get explicit numbers for both from the business before designing anything, match SQL Server replication mode to the RPO target and web/app tier readiness to the RTO target, and keep the standby's customization package in lockstep with production at all times, because a DR failover that surfaces stale code is a second incident, not a recovery.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.