A backup strategy for SMEs that actually works

A backup that works when it matters needs three things: several independent copies of the data, at least one of them physically separate from the original, and restores that are tested regularly – not just a backup job that runs overnight while nobody checks the result. Those exact three points are where most backup strategies fail in practice, usually not out of carelessness but because they grew organically over years and were never rethought from scratch.

The 3-2-1 principle as a foundation

The 3-2-1 principle is a long-established rule of thumb for data backup and a good starting point for any backup strategy: three copies of the data, on two different types of media, with one copy kept off-site. The idea behind it is simple – any single copy can be lost for a different reason, and combining several copies across different media and different locations covers the realistic failure scenarios without having to reason through each one individually.

• Three copies: the original plus at least two backups
• Two media types: e.g. a local backup on a NAS plus a cloud or tape backup, rather than the same medium twice
• One copy off-site: protects against events affecting the whole site (fire, water damage, theft)

Why an offsite backup isn't a nice-to-have

A backup sitting in the same server room as the original protects against plenty of failures – just not the ones affecting the whole room. A fire, water damage, a break-in where both devices get taken: none of these are exotic scenarios, they're the exact reason the 3-2-1 principle calls for a physically separate copy in the first place. Offsite can mean a second company location, an external data centre, or cloud storage – what matters is only that a local event at the main site doesn't also affect the external copy.

Local, cloud, or both

Choosing the second medium for the 3-2-1 principle almost always raises the question of whether a cloud backup, a second physical site, or a combination of both makes more sense. A purely local backup is usually faster to restore because it doesn't depend on your own internet connection – but without a further, physically separate location it isn't a complete implementation of the 3-2-1 principle. A cloud backup is automatically off-site and therefore well suited as the offsite copy, but can become a bottleneck for large data volumes over a slow internet connection when a full restore is genuinely needed. In practice, a combination works best for most businesses: a fast local backup for everyday use, complemented by a cloud or offsite copy for the case where the main site itself is affected.

How often you should back up

How often a system needs backing up depends on how much data loss would be tolerable in an emergency – a file server with occasional changes needs a different backup frequency than a system where orders or customer data are being entered continuously. Rather than setting one uniform frequency for the whole infrastructure, it's worth thinking through, system by system, how much work or data could realistically be lost between two backups in the worst case.

• Decide, system by system, how much data loss would be tolerable in the worst case
• Back up systems with frequent changes (e.g. order management, inventory) more often than static file shares
• Consider backup frequency and retention period separately – frequent backups don't help much if older generations get overwritten too soon
• Schedule backup windows so they don't noticeably disrupt ongoing operations

Restore testing: the part that's usually missing

A backup that has never been restored is an assumption, not a safety net. In practice, the nightly backup job often runs reliably – right up until the day it's actually needed and it turns out part of the data was corrupted, incomplete, or from an incompatible version. Regular restore tests are the only way to find that out beforehand instead of learning it during a real emergency.

• Run and log spot-check restores of individual files on a regular basis
• Test a full restore of an entire system at least once a year, not just individual files
• Assess restore time realistically: how long it actually takes to get a system running again
• Document the results of the tests so weaknesses in the strategy become visible instead of staying hidden

Ransomware resilience: backups an attacker can't encrypt too

Modern ransomware actively hunts for reachable backup systems and encrypts or deletes them before going after the actual production data – a backup that's permanently online and connected to the production network offers an open attack surface for exactly that. A resilient backup strategy therefore separates the backup technically or in time from the rest of the network, rather than leaving it permanently reachable.

• Keep at least one copy offline or immutable, so it can't be altered even if an attacker gains full network access
• Manage the backup system with different credentials than the production system
• Retain staggered backups (multiple generations) so an unnoticed encrypted version can still be rolled back
• Restrict access to the backup management itself just as tightly as any other sensitive system

Common gaps in backup strategies that grew organically

Backup strategies are rarely designed on a blank sheet of paper – they usually grow over years, one system gets connected after another, and at some point somebody loses track of what's actually fully backed up and what isn't. The typical gaps almost always show up in the same places.

• New systems (e.g. a new line-of-business application or a new server) go live without being added to the existing backup routine
• Cloud services such as hosted email or SaaS applications get wrongly assumed to be "already backed up", even though the provider often only guarantees availability, not a backup of your data
• Configuration data for network devices (firewall, switches) is missing from the backup, even though restoring it matters just as much in an emergency as restoring the servers
• Backup jobs run, but nobody gets notified when one fails – the gap only surfaces when it's actually needed