A backup is a restore that worked
Ask a small-business owner whether they have backups and almost everyone says yes. Ask when they last restored a file from one and the room goes quiet. That gap is where businesses disappear.
The job reports success. The restore fails.
Backup software is optimistic by design. It will tell you a job succeeded when it copied files it could read to a destination it could write. It will not tell you that the database was mid-transaction and the copy is inconsistent, that the destination drive has been silently failing for months, that the job has been backing up a shortcut rather than a folder since someone reorganized the share, or that the "cloud" copy is a sync folder that faithfully replicated the ransomware encryption at 2 a.m.
Every one of those is a real case we've walked into. In each, the dashboard was green.
Three questions before three copies
The industry rule of thumb is 3-2-1: three copies, two media, one off-site. It's good, but it skips the step that gives it meaning. Before designing anything, answer three questions per system:
- How long can we be without this? That's your recovery time objective. For a practice-management system it might be four hours; for an archive of old projects, a week.
- How much work can we afford to redo? That's your recovery point objective: how old the most recent backup is allowed to be. Nightly means a bad day costs a day.
- What are we protecting against? A dead disk, a deleted folder, a compromised account, a fire, a disgruntled ex-employee. Each needs a different copy to survive it.
Only once those numbers exist can you tell whether a given design is good enough — and whether you're paying for more than you need.
The copy ransomware can't reach
Modern ransomware groups look for backups first and encrypt or delete them before they hit production. A backup the attacker's stolen admin credentials can delete is not a backup against ransomware. You want at least one copy that is immutable (the storage refuses deletion for a retention window regardless of credentials) or offline (physically disconnected, rotated). Several backup appliances and cloud object stores offer immutability for little extra; it's the single most valuable checkbox in the product.
The habit: a monthly restore
Once a month, restore something real. Not a text file: the accounting database to a test machine, a whole VM to a sandbox, last Tuesday's version of a client folder. Time it. Write down what you had to know to do it (which console, which credentials, which order). That note becomes your recovery runbook, and the timing becomes evidence that your recovery time objective is true rather than hoped.
If that sounds like too much effort, that's the point: it is exactly the effort you'd have to make on the worst day of your business, and far better to discover the gaps on an ordinary Tuesday.
We include a monthly test restore in every managed plan and put the result in the client's report. Not because it's hard, but because it's the step everyone skips.
Microsoft 365 is not backing you up
One more place the dashboard lies by omission. Microsoft and Google keep your data highly available: their hardware failing won't lose it. Your deletions, a compromised account purging a mailbox, or a sync client faithfully propagating encrypted files are a different matter, and their default retention is short. If your business lives in 365 or Workspace, it needs a backup of that too.
If you're not sure which of these describes your setup, the fastest way to find out is to pick a file from six months ago and try to get it back. We're happy to watch you do it.