Backup and recovery strategy for SMEs: the practical guide

Why "we have backups" isn't the same as "we can recover"

Having backup files and having a tested recovery process are two very different things. Backups that have never been restored are assumptions, not insurance. They represent a hope – that the data is complete, that the restore procedure works, that the recovered state is recent enough to be useful – rather than a confirmed capability.

Three things organisations typically discover too late: the backups were incomplete (certain databases, application configurations or email data weren't included in the scope); restoration takes far longer than expected (what seemed like a simple file restore turns into a multi-day rebuild when the underlying infrastructure also needs rebuilding); or the recovered data is weeks old because the backup frequency didn't match the rate of change in the business.

None of these failures are obvious until the moment you need to recover. That's what makes backup testing so important – and so routinely skipped. The failure mode is invisible until it's critical.

The 3-2-1 rule and why it still matters

The 3-2-1 rule remains the baseline for sound backup architecture: three copies of your data, stored on two different media types, with one copy held offsite. It's a principle that has survived several decades of technology change because it addresses the most common failure scenarios – hardware failure, local disaster and accidental deletion – with a simple, checkable structure.

Ransomware has made one part of that rule significantly more urgent. The "one copy offsite" requirement was originally about protecting against physical disasters – fire, flood, theft. In a ransomware context, offsite isn't enough on its own. If your offsite backup target is network-accessible from your production environment, ransomware can reach it. Many attacks now specifically target backup systems as part of the initial compromise – because attackers know that an intact backup is the primary alternative to paying the ransom.

The current best practice is immutable backups: a backup target where data is written once and cannot be modified, overwritten or deleted for a defined retention period, even by an administrator with full credentials. Most modern backup platforms support immutability natively. An attacker who has compromised your systems and your backup admin account still cannot touch an immutable backup target. That's the protection that cloud sync services – OneDrive, Dropbox, Google Drive – do not provide. Sync replicates whatever is in your production environment, including encrypted ransomware files. It is not a backup.

RTO and RPO without the jargon

Two terms come up in every serious conversation about backup and recovery. Most SMEs have heard them; far fewer have defined them for their own business.

Recovery Time Objective (RTO) is the maximum amount of time the business can be offline before the disruption becomes critical. This isn't a technical figure – it's a business one. Can you operate without your systems for two hours? Eight hours? Two days? The answer depends on your business model, your contractual obligations to clients and the processes that depend on your IT infrastructure. Whatever that figure is, your recovery architecture needs to be capable of meeting it.

Recovery Point Objective (RPO) is the maximum amount of data loss the business can tolerate, measured in time. If you back up nightly and your RPO is 24 hours, you're accepting that in a worst-case recovery you'll lose up to a full day's work. If that's not acceptable – because your data changes rapidly, because you have compliance obligations, or because a day's transactions represent significant value – you need more frequent backups or continuous data protection.

These two figures drive every practical decision about backup architecture: how often to back up, how quickly recovery infrastructure needs to spin up, how much to invest in hot standby versus cold restore. Without defined RTO and RPO, you're designing a backup system without a specification.

What to back up and how often

A common gap in SME backup strategies is incomplete scope. The backup job runs successfully, the monitoring reports green, and no one notices that three critical systems weren't included.

The full scope should cover: file data (including mapped drives and shared storage), databases (including line-of-business application databases that aren't stored as simple files), email (see below), application configurations (so systems can be rebuilt without starting from scratch), and virtual machine images for any on-premise or cloud-hosted servers.

Microsoft 365 is one of the most common gaps. Microsoft provides basic retention policies within the 365 platform, but these are not a backup. Deleted items are recoverable for a limited period; after that, the data is gone. Microsoft's own documentation recommends third-party backup for 365 data – email, SharePoint, Teams, OneDrive – if retention and recovery are important to you. For most businesses they are, and a dedicated 365 backup solution is a relatively low-cost fix for a significant vulnerability.

Backup frequency should be set to match your RPO. If your RPO is four hours, a nightly backup job doesn't meet it. If your RPO is 24 hours and you're backing up hourly, you're spending more than necessary. The frequency decision should be made deliberately, not inherited from a default configuration.

Testing your backups

There are two separate activities that businesses often conflate: backup monitoring and backup testing. Both matter, and neither replaces the other.

Backup monitoring is checking that the backup job ran, completed without errors and produced output of the expected size. This is a daily hygiene task. It tells you the backup process is functioning. It tells you nothing about whether the backup can be successfully restored.

Backup testing is restoring from a backup to a clean environment and confirming that the recovered data and systems are actually usable. This is the exercise most organisations skip. It requires time, a test environment and someone to own the process – and it often reveals problems that monitoring never would. Corrupted backup files, restore procedures that only work for some data types, dependencies on infrastructure that wasn't included in the restore scope, restore times that far exceed what the business assumed.

The recommended minimum is a full restore test quarterly, with the results documented: what was restored, how long it took, what the recovered state was and who ran the test. That documentation serves two purposes. Operationally, it gives you a realistic figure for restore time – one you can actually use when someone asks "how long will recovery take?" during an incident. Commercially, it's evidence for your insurer and for Cyber Essentials assessors that your backup capability is real, not theoretical.

What Cyber Essentials and insurers require

Cyber Essentials covers backups as one of its five technical controls, though the scheme's requirements in this area are relatively high-level. The focus is on ensuring that data can be recovered in the event of a cyber attack – which means having backups that are separate from the main environment and protected against ransomware. Immutability and offsite storage address this requirement directly.

Cyber insurance questionnaires have become considerably more detailed on backup, reflecting the frequency of backup-related claims. Insurers now routinely ask about: how often backups run, whether offsite or air-gapped copies exist, whether backups are immutable, and – critically – whether restore tests have been performed and documented. Answering these questions honestly matters. If you disclose controls you don't actually have and a claim arises, your insurer has grounds to dispute coverage.

It's worth being clear about what a strong backup strategy does and doesn't do. It doesn't prevent a ransomware attack. It doesn't stop data being exfiltrated before encryption – which is increasingly common and creates a separate exposure. What it determines is the cost of recovery. A business with tested, immutable, offsite backups and a defined RTO/RPO may face a recovery bill of £10,000 to £30,000. A business without those things – facing the choice between paying a ransom or losing weeks of data – is looking at a very different number.