Every business we walk into says they have backups. Maybe half actually do, and maybe half of those could recover from them under pressure. The gap between "we back things up" and "we could be running again by Monday" is where companies get hurt. Ransomware, a deleted database, a flooded office, a fired employee with a grudge: the cause does not matter much. What matters is two numbers you decided on ahead of time, or did not.
RPO and RTO in plain English
Disaster recovery planning sounds complicated, but the whole field boils down to two questions.
RPO, recovery point objective: how much work can you afford to lose? If your last good backup is from midnight and the server dies at 4 PM, you lose 16 hours of invoices, emails, and edits. If that is acceptable, a nightly backup meets your RPO. If losing more than an hour of order data would be a real problem, you need backups (or replication) running much more often, and that costs more.
RTO, recovery time objective: how long can you afford to be down? Not how long the restore takes in theory. How long from "everything is broken" to "staff are working again," including the time it takes to notice, decide, find the credentials, and actually do it. A company that can limp along on paper for two days has a very different RTO than a shop where the phones stop making money the moment the system is down.
Every dollar in a DR budget buys down one of those two numbers. Tighter RPO means more frequent backups. Tighter RTO means standby systems that are ready to take over faster. Decide the numbers first, then buy exactly enough to hit them. Most small businesses land somewhere around "lose at most a few hours, back up within a day," and that is a reasonable, affordable target.
What a real backup setup looks like
The old rule still holds: three copies of your data, on two different types of storage, with one copy off-site. In practice for a small business that usually means the live data, a local backup for fast restores, and a cloud copy for when the building itself is the problem.
Two details matter more than people think.
- One copy must be unreachable from your network. Ransomware crews specifically hunt down backups and encrypt or delete them before triggering the attack. A backup drive that is always mounted, or a cloud sync your admin account can delete, does not count. You want immutable or offline copies: cloud object storage with versioning and delete protection, or backups the backup software can write to but nothing can erase for 30 days.
- Restores get tested, on a schedule. An untested backup is a rumor. Once a quarter, actually restore a file, a mailbox, and ideally a whole server to somewhere harmless, and time it. This is the single step most businesses skip, and it is the one that determines whether the plan works.
What this costs at small-business scale
Less than people fear. For a typical small business with a server or two and a Microsoft 365 or Google Workspace tenant, the moving parts are:
- Cloud backup storage: typically tens of dollars a month, scaling with how much data you keep and for how long. A few terabytes of backup history is not expensive anymore.
- Backup software licensing: per-server or per-user, usually a modest monthly line item.
- Microsoft 365 / Google Workspace backup: a few dollars per user per month. Yes, you need this. Microsoft keeps your service running; they do not promise to recover the mailbox someone emptied six months ago.
- The plan and the testing: a few hours to set up properly, and a couple of hours a quarter to test. This is labor, not product, and it is where most of the real value lives.
All in, a solid backup and DR posture for a 10 to 30 person company usually runs in the low hundreds of dollars a month. Compare that to the going rate for a ransomware incident or a week of the whole staff idle, and it is one of the cheapest forms of insurance a business can buy.
The plan itself: one page, printed
A DR plan does not need to be a binder. One page covers it: what gets backed up and how often, where the copies live, who to call, where the passwords and encryption keys are kept (somewhere that survives the disaster, not on the dead server), and the restore steps in order. Print it. If the disaster takes out your file server, the plan stored on the file server goes with it.
How you know it is done right
You can answer four questions without looking anything up. What is our RPO and RTO? Where is the copy that ransomware cannot touch? When did we last test a restore, and how long did it take? Who runs the recovery if the usual person is on a plane? If all four have real answers, you have a plan. If any of them get a shrug, you have hope, and hope is not a strategy we recommend.
We set these up regularly: pick the numbers, build the backup chain, run the first test restore with you, and leave you with the one-page plan.
Stuck on this, or want it done for you? That's the job.
Email us →