Most disaster recovery conversations happen after something’s gone wrong, at which point it’s too late to negotiate anything. The right time to ask hard questions about backups, downtime and recovery is before you sign, when you still have leverage and the vendor still wants your business.
TL;DR
- “Uptime SLA” and “disaster recovery” aren’t the same commitment. One covers whether the system’s generally available, the other covers what happens after a genuine failure.
- Two numbers matter more than any marketing claim: how fast can they restore the system, and how much data could you lose.
- Moving to the cloud doesn’t automatically mean the vendor handles everything. Ask exactly where their responsibility ends and yours begins.
- A disaster recovery plan nobody’s tested is just a document, not a guarantee.
- Blue Lotus 360’s cloud infrastructure includes defined backup and recovery commitments as standard, not something negotiated after the fact.
The two numbers worth asking for directly
Vendors will happily talk about uptime percentages. Fewer will volunteer two more specific figures that actually matter when something breaks: how long it takes to get you back up, and how much data you’d lose in the process.
“What’s your Recovery Time Objective?” This is how long the system can realistically be down before it’s restored. If a vendor’s answer is vague, “we aim to restore as quickly as possible”, that’s not a commitment, it’s a hope. Push for an actual figure: four hours, eight hours, whatever it is, and get it in writing.
“What’s your Recovery Point Objective?” This is the flip side: how much data could you lose. An RPO of one hour means that in the worst case, you’d lose up to an hour of transactions, orders, invoices, updates, since the last successful backup point. For a business running live sales or production data, the difference between a one-hour RPO and a 24-hour one is the difference between a bad afternoon and a genuinely painful week reconstructing what happened.
Neither number needs to be perfect. They need to be honest, specific, and something you can actually plan around.
What “we’re on the cloud” doesn’t automatically cover
It’s a common assumption that moving to cloud ERP hands disaster recovery entirely to the vendor. In practice, most cloud arrangements split responsibility rather than transfer it completely.
The vendor typically owns the infrastructure side: keeping the data centres running, the platform generally available, the underlying servers resilient. What often stays less clearly defined is the data layer: how often your specific data is backed up, where those backups are stored, and who’s actually responsible for pulling the trigger on a restore if something goes wrong.
“If your platform goes down, who’s responsible for getting my data back, and how quickly?” is worth asking plainly, rather than assuming the answer is obviously “you, the vendor.” Get the answer in writing, not as a verbal reassurance during a sales call.
Direct questions worth asking about backups
A handful of specific questions here tend to separate a vendor with a genuine plan from one working off assumptions:
- How often is my data actually backed up, and is that a full backup or continuous logging between snapshots?
- How long are backups retained before they’re overwritten or deleted?
- Are backups stored in a different physical location from the live system, so one incident can’t take out both?
- Can I access or export my own backup data if I need to, independently of the vendor?
- What actually counts as a “disaster” under this agreement? Does it cover accidental deletion and a bad software update, or only major infrastructure failure?
That last question catches more people out than it should. A backup regime that only kicks in for a full data centre outage is very different from one that also covers someone accidentally deleting a customer record.
The question vendors would rather you didn’t ask
Anyone can write an impressive-looking recovery time into a contract. Whether it’s actually achievable is a different matter entirely, and the only way to know is testing.
“When did you last actually test a full recovery, and can I see the results?” A vendor that runs regular failover tests and can show you documented outcomes, what worked, what didn’t, what got fixed, is demonstrating a plan that’s been proven under something resembling real conditions. A vendor that can’t answer this clearly is asking you to take their recovery promise on faith.
If a vendor bristles at being asked this, treat that as useful information in itself.
Where Blue Lotus 360 stands on this
Blue Lotus 360’s cloud infrastructure runs on defined backup and recovery commitments as a standard part of the service, not something bolted on for enterprise clients willing to pay extra. Backups run on a regular schedule, are stored separately from the live environment, and recovery procedures are something the team can speak to directly rather than gesture vaguely at.
If you’re evaluating ERP vendors and disaster recovery hasn’t come up yet in the conversation, that’s worth raising directly. A demo is a reasonable place to ask these exact questions and see how confidently they’re answered.
FAQ Section
What’s the difference between an uptime SLA and disaster recovery?
An uptime SLA covers how often the system is generally available under normal conditions, expressed as a percentage like 99.9%. Disaster recovery covers what happens after a genuine failure: how quickly the system’s restored and how much data is recoverable. A strong uptime figure says very little about what happens on a bad day.
Is a 99.9% uptime SLA actually good?
It sounds high, and in practice it still allows for several hours of downtime across a year. The percentage matters less than understanding what counts against it, and what the vendor commits to if a genuine outage happens beyond that.
Do small businesses really need to ask about RTO and RPO, or is that only for large enterprises?
Any business running live operational data through its ERP has a real stake in these numbers, regardless of size. A smaller business often has less slack to absorb a bad recovery outcome, not more, since there’s rarely a backup team or manual workaround to fall back on.
What should I do if a vendor can’t give me a specific RTO or RPO figure?
Treat it as a genuine red flag rather than a minor gap. A vendor without a specific, testable figure either hasn’t planned for this properly or isn’t willing to commit to it in writing, and neither is a good sign before you sign a contract.
