Most organisations have backups. Far fewer can tell you how much data they would lose in an incident, or how long they would be down. Those two numbers are the plan; everything else is storage.
Never defining RPO and RTO
Recovery point objective is how much data you can afford to lose — the gap between the incident and the last good backup. Recovery time objective is how long you can afford to be down.
Until both are written down and agreed by whoever carries the business risk, you cannot evaluate a backup setup, because there is no target to evaluate against. Nightly backups are excellent if your RPO is a day and useless if it is an hour.
Backups in the same account or region
A copy in the same cloud account protects against deletion and corruption. It does not protect against account compromise, a billing suspension, or a region-wide outage — and those are the scenarios where you actually need it.
At least one copy should sit somewhere with different credentials. If a single compromised login can delete both the data and its backups, you do not have backups.
No immutability against ransomware
Modern ransomware looks for backups first, because encrypting them is what makes the ransom work. Reachable network shares and mounted volumes are found and encrypted alongside everything else.
Versioned, immutable storage — where a copy cannot be altered or deleted for a set period, even with valid credentials — is the specific defence. This is one case where a feature name is worth insisting on.
Backing up the VM but not the database consistently
A snapshot of a running server captures the database mid-write. It restores, and the data is subtly corrupt — sometimes not obviously, which is worse.
Databases need their own backup process that produces a consistent point in time. A file-level copy of a live database is not that.
Forgetting SaaS data entirely
Email, shared drives, the CRM. The provider guarantees their infrastructure; they generally do not guarantee recovery of data your own users deleted, beyond a short retention window. An employee clearing a mailbox, or a departing user's account being removed, can be permanent.
Read the shared responsibility terms of the platforms you depend on. The gap is usually bigger than expected.
A plan that lives in one person's head
The person who knows the restore procedure is on leave, or has left. Nobody else knows the order systems must come back in, or which credentials are needed, or where they are stored.
Write the runbook, store it somewhere reachable when the primary systems are down, and have someone else follow it once. If they cannot, it is not a runbook.
The test that tells you the truth
Pick a system. Restore it to somewhere isolated. Time it. Note everything that was missing, wrong, or needed a person who was not in the room.
That number and that list are your real disaster recovery position. Everything before the test is an assumption.
About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.
Gallery
