Ask any owner if they have backups and the answer is yes. Ask when they last restored something from those backups and the room goes quiet. That silence is the whole topic: an untested backup is a hope with a subscription fee, and the difference between hope and evidence gets discovered at the worst possible moment — after the ransomware, the dead server, the deleted folder, the departed employee. Here's the backup architecture that actually survives contact with disaster, sized for an SME.
First, inventory what would actually hurt
Backups fail most often by omission: the system was backed up, but the thing you needed wasn't in it. Spend thirty minutes listing what loss would damage: the accounting file, the job/CRM data, the shared documents, email, the website, the specialised app's database (the quoting tool, the design files, the practice management system), and the awkward stragglers — the spreadsheet on someone's desktop, the photos on the site supervisor's phone, the config of the systems themselves (who could rebuild your phone routing or your POS settings from nothing?). For each: where does it live, what backs it up, and who would know. The inventory usually finds two or three critical items protected by nothing but luck.
The architecture: 3-2-1 in plain terms
The standard worth adopting is boring and battle-proven — three copies of anything important, on two different types of storage, with one copy off-site and offline-or-isolated: the live data, a local/fast backup for quick everyday restores, and a separated copy that survives the events that take out the first two. The separation matters more than the count: a backup drive permanently plugged into the server gets encrypted by the same ransomware; a sync folder replicates the deletion it was meant to protect against. The third copy must be somewhere an attacker (or an angry insider, or a flood) who owns your network can't reach — immutable cloud backup storage, versioned with retention, or genuinely rotated offline media for the old-school version.
"It's in the cloud" is half a strategy
The most common SME misconception deserves its own section: Microsoft 365, Google Workspace, Xero, your job platform — these are highly available, which is not the same as backed up for your failure modes. The platforms protect against their disks dying; they faithfully replicate your mistakes — the deletion, the overwrite, the malicious mass-edit, the account takeover — and their native retention windows are finite and not designed as your archive. The fixes are cheap and specific: third-party backup for 365/Workspace (mail, drives, sites — versioned, independently stored), regular exports of the SaaS data you can't live without (most platforms have export APIs or scheduled reports; test that the export actually opens and contains what you think), and for the accounting file, knowing exactly what your platform's restore options are before you need them. The question to ask every cloud vendor once: if we delete or corrupt our own data, what can you restore, and how far back? The answers vary more than owners assume.
The restore drill: quarterly, small, real
Now the part that converts hope to evidence. Once a quarter, restore something for real: a file from three weeks ago, a mailbox folder, last month's accounting data into a test environment — rotating through your critical systems across the year. You're testing four things at once: the backup actually contains the data (corruption and silent job-failures are common), the restore process works and someone knows how to drive it, the time it takes matches your tolerance (a restore that takes four days is a strategy problem you want to discover on a Tuesday, not mid-crisis), and the credentials/keys needed aren't locked inside the very system that's down. Log the drill in two lines — date, what, result, duration. Four entries a year is the entire audit trail, and it's also the difference between "we have backups" and "we restored payroll data in forty minutes last quarter" — one of which means something to insurers, auditors and your own sleep.
Pair the drill with monitoring's minimum: backup job failure alerts that go to a human who reacts (the saddest post-incident discovery is the backup that had been failing, politely and unread, for eight months).
FAQ
How long should we keep backups?
Versioned retention beats single-snapshot: enough history to recover from problems discovered late (corruption and breaches are often found weeks in) — commonly daily points for a month and monthly points for a year — plus whatever your record-keeping obligations require for financial data. Storage is cheap; missing history isn't.
Who should own this?
One named person owns verification (the alerts, the quarterly drill), even if an IT provider runs the plumbing. "The IT company handles it" is fine only alongside "and here's last quarter's restore log proving it."
What about the laptops and phones?
Policy plus platform: critical work lives in the synced/backed-up locations (and the BYOD rules we've covered keep it there), devices themselves encrypted and wipeable. The goal is that any single device can be lost on a train tonight and cost you hardware, not data.
Backup integrity is one of the checks in our free Business Health Check — five minutes to find out whether you're holding evidence or hopes.
About the author
Nick Lucock
Chief Executive Officer, Valont
Nick leads Valont's day-to-day operations across Finance, People, Operations and Growth. He writes about how the work actually gets done, the processes, systems, and tools that keep Australian SMEs compliant and growing.
LinkedIn →