Most businesses only find out how good their backup strategy is when something has already gone wrong: a dropped database table, a botched migration, a ransomware note, or a cloud region that quietly falls over on a Tuesday afternoon. By then the questions that mattered — how far back can we restore, how long will it take, does anyone actually know the procedure — have already been answered, badly, by the incident itself.
If you are commissioning software, or already run a system built by someone else, backup and disaster recovery is not a checkbox to tick after launch. It is a set of engineering decisions that should be visible in the contract and the architecture before the first line of code ships. Here is what to actually ask, and why the answers matter more than the marketing language around them.
Start with RPO and RTO, not “we do backups”
“We take regular backups” tells you almost nothing. Two numbers do the real work:
- Recovery Point Objective (RPO) — how much data you can afford to lose, measured in time. If backups run nightly and the RPO is 24 hours, a failure at 5pm loses a full day of orders, bookings or transactions.
- Recovery Time Objective (RTO) — how long the system can be down before the business is materially hurt. An internal reporting tool might tolerate a day. A booking system or payment flow usually cannot.
These numbers should be set deliberately, by whoever owns the business risk, not left as a side effect of whatever backup schedule a hosting provider defaults to. A vendor who cannot state your RPO and RTO in figures hasn’t designed for them — they’ve just enabled a default and hoped.
Different parts of a system can carry different numbers. Financial records and customer data usually justify a tighter RPO than, say, cached analytics or log data that can be regenerated. Paying for the tightest possible recovery everywhere is expensive and rarely necessary; the point of asking is to make that trade-off on purpose.
Where do the backups actually live?
A backup stored in the same account, same region, and same provider as the live system protects against far fewer failure modes than it looks like it does. It covers accidental deletion and hardware faults. It does not cover a compromised admin account, a billing dispute that locks the account, or a regional outage.
The long-standing rule of thumb is 3-2-1: at least three copies of the data, on two different types of storage, with one copy kept somewhere genuinely separate — a different provider, a different account, or offline entirely. It is not always proportionate for a small internal tool. It is worth insisting on for anything that holds customer data, financial records, or the only copy of work your business depends on.
Worth asking directly: if our cloud account were suspended or compromised tomorrow, where is the nearest usable copy of our data, and who can access it?
Who is actually responsible, and where does that end?
Cloud providers operate on a shared responsibility model. AWS, Google Cloud and Azure will all keep their infrastructure running and, for managed database services, typically offer automated backups and point-in-time recovery as a configurable feature — not something that happens by default at every tier. Whether that feature is switched on, tested, and retained for long enough is down to whoever configured your environment.
That distinction matters when you’re comparing quotes or reading a support agreement. “Hosted on AWS” is not the same statement as “backed up.” Ask your development team, agency or in-house engineers to say explicitly which parts of recovery the cloud platform handles automatically, and which parts someone has to build, configure and monitor. If nobody can answer that clearly, treat it as a gap rather than a formality.
A backup you haven’t restored is a hope, not a plan
Backup jobs fail silently more often than most people expect: a credentials rotation breaks the export script, a schema change makes an old snapshot incompatible, storage quietly fills up and the job starts skipping files. None of this shows up until someone tries to restore from it.
A restore test is the only way to know a backup strategy works. That means actually rebuilding the system, or at least the data, from the backup on a schedule — quarterly is a reasonable starting point for most small businesses — and timing how long it takes. If the answer to “when did you last restore from backup and how long did it take” is “we haven’t,” the RTO you agreed on paper is fictional.
What this looks like in a real project
On the systems we build, backup and recovery decisions get made at the same stage as the database and infrastructure choices, not bolted on afterwards. That means agreeing RPO and RTO figures per data category with the client before the schema is finalised, documenting exactly which recovery mechanisms the cloud provider handles automatically versus what we configure ourselves, and putting a restore test on the maintenance schedule rather than leaving it as a one-off at launch. None of this is exotic engineering — it’s mostly a matter of writing the decisions down and actually exercising them, which is precisely the step most projects skip under deadline pressure.
Questions worth putting to any vendor
- What is our RPO and RTO, in hours, for each category of data we hold?
- Where do backups live relative to the live system, and what single event could take out both at once?
- Which recovery features are handled automatically by the cloud provider, and which are configured and monitored by you?
- When was a restore last actually tested, and how long did it take?
- Who is notified, and what is the procedure, if a backup job fails?
- How long are backups retained, and does that meet any regulatory or contractual requirement you have (for example, financial record-keeping periods)?
If a vendor answers all six without hesitation, that’s a reasonable signal they’ve actually built recovery into the system rather than assumed it. If they can’t, it doesn’t necessarily mean the project is unsafe to proceed with — but it does mean these decisions haven’t been made yet, and they’re worth making before launch rather than after the first serious incident.