Most small offices think they have backups. Many discover, when they need to restore, that they don't — or that what they have is incomplete, outdated, or inaccessible. Here is what a backup that actually works looks like.
One of the first things IT support providers hear after a data loss incident is: "We thought we had backups." The storage drive was there. The folder was named "Backup". Someone set something up a while ago. But when the moment came — a failed hard drive, a ransomware attack, an accidental deletion — the backup didn't restore, or didn't contain what was needed, or had not run in six months. A backup that can't restore isn't a backup. It's the appearance of a backup, which is in some ways worse than having none at all, because it creates a false sense of security that delays the recognition of real risk. This guide is a practical checklist for small offices who want to verify that their backup actually works — before they need it. This guide covers: - What needs to be backed up (and what's often missed) - Where backups should be stored - How frequently backups should run - How to test whether a backup will actually restore - The checklist to run now ## What Needs to Be Backed Up The goal of a backup is to restore the organisation's ability to operate after a failure. That means identifying everything the organisation can't function without and ensuring it's in the backup. **Business data.** Documents, spreadsheets, databases, financial records — anything stored in files on local machines or servers. If it's in a file and changes regularly, it needs to be in the backup. **Email.** For most small offices, email is the record of decisions, commitments, and correspondence. Cloud-based email (Microsoft 365, Google Workspace) has its own retention and recovery tools, but those aren't the same as a backup — they have retention limits and are controlled by the provider. Understand what your email platform retains and for how long. **Accounting and payroll data.** If your accounting software stores data locally (rather than entirely in the cloud), that data needs to be explicitly included in your backup. Accounting data is often stored in a location that default backup configurations miss. Confirm where it's stored and confirm it's backed up. **Configuration and system data.** For organisations running servers, network devices, or specialised software, configuration data — the settings that define how systems work — may be as important as the data itself. Rebuilding a server from scratch takes much longer than restoring a configuration backup. **What's often missed:** data stored on individual staff laptops rather than on a shared drive or server; data in cloud applications that have their own data (a project management tool, a CRM) that requires a separate export or backup configuration; and data on mobile devices. > Many small offices back up the server and forget the laptops. When the laptop fails, the work of weeks or months is gone. ## Where Backups Should Be Stored The critical principle: backups must be stored somewhere different from the original data. A backup stored on the same device as the original is destroyed in the same hardware failure. A backup stored on a drive in the same building is destroyed in the same fire or flood. Ransomware that encrypts the organisation's files frequently also encrypts locally connected backup drives. **Off-site storage** — a cloud backup service, or a physical drive that is regularly taken off-premises and swapped — protects against local failures. Cloud backup services (Backblaze, Veeam Backup, Azure Backup, or equivalents) provide reliable, automated off-site storage at low cost for most small office data volumes. **The 3-2-1 rule** is a widely used guideline: three copies of the data, on two different media types, with one copy off-site. For a small office, this might mean: local files, a daily backup to a local NAS (network-attached storage), and a weekly or daily sync to cloud backup storage. ## How Frequently Backups Should Run Backup frequency should match the cost of losing data since the last backup. For data that changes daily — documents, financial records, programme data — daily backups are the minimum. For data that changes in real time, more frequent backups or a continuous backup solution is worth considering. **Recovery Point Objective (RPO)** is the answer to: how much data can we afford to lose? If losing one day's work is acceptable, daily backups are sufficient. If losing an hour's work isn't, backups need to run more frequently. Define this explicitly — the default assumption that "recent enough is fine" is how organisations discover that "recent" was three weeks ago. ## How to Test Whether a Backup Will Actually Restore The only way to know a backup works is to restore from it. This isn't optional — a backup that has never been tested is an unverified claim. Testing doesn't require a full disaster simulation. It can be as simple as: select a file that was backed up, delete it from the original location, and restore it from the backup. Did the restore work? Did the restored file match the original? How long did it take? For more comprehensive testing:...