The rule and its reason

Three copies of your data. Two different types of media. One copy offsite.

The 3-2-1 rule exists because every backup method has a failure mode. A hard drive fails — they all do, eventually. Mechanical drives have a mean time between failures of three to five years. Solid-state drives last longer but fail without warning. A building floods. A fire takes the server room and the NAS sitting on the shelf above it. Ransomware encrypts everything on the network, and the backup drive was mounted as a network share — so the ransomware encrypted that too.

The rule ensures no single failure — mechanical, environmental, or adversarial — destroys all copies of your data. It is not a suggestion. It is not best practice in the advisory sense where "best practice" means "something you should probably get around to." It is the minimum.

Everyone knows the rule. Almost nobody tests the restore.

What to back up

Not everything. Back up the data the business cannot recreate. Identify it explicitly and write the list down.

Financial records — invoices, accounts payable and receivable, payroll records, tax submissions, bank reconciliations. These are legally required under HMRC rules for six years and commercially essential for continuity.

Customer data — contracts, correspondence, CRM records, order histories, support tickets. This is the data that defines your customer relationships. Losing it means starting those relationships again from memory and email archives.

Project files — deliverables, work in progress, design files, specifications, proposals. The output of your team's work.

Email archives — years of institutional knowledge live in mailboxes. Decisions, agreements, context, and audit trails. Email is often the system of record for things that should have been documented elsewhere but were not.

Configuration — settings for critical systems, firewall rules, DNS zone files, application configuration files, server build documentation. These are small files that are catastrophically time-consuming to recreate from scratch.

Exclude what can be reinstalled. Operating systems, applications, anything available from a vendor's download page or a software repository — these can be rebuilt from installation media. Back up the data, not the infrastructure. Infrastructure can be rebuilt in hours. Data cannot be rebuilt at all.

A common mistake: backing up an entire server image — operating system, applications, data, temporary files, the lot — resulting in a 500 GB backup file. The backup runs every night. It has run every night for two years. Nobody has ever tested whether it restores. The backup file is a comfort object, not a recovery tool. When the day comes, it may restore. It may not. You will discover which only when you cannot afford the answer to be "not."

Windows Server Backup

Built-in. Free. Adequate for small deployments with simple requirements.

Open Server Manager → Add Features → Windows Server Backup. Configure a backup schedule — daily is the minimum. Schedule it overnight when the server is least busy and users are not working. Select the volumes or folders to back up. Target an external USB drive or a network share on a separate device.

The limitation: Windows Server Backup does full-volume or folder-level backups. It does not do application-aware backups for Exchange or SQL Server. Application-aware means the backup tool communicates with the application before taking the snapshot — it tells Exchange or SQL to flush its buffers and reach a consistent state, a process called quiescing. Without this, the backup captures the database mid-transaction. The database files are internally inconsistent. The backup may be unrestorable, or it may restore to a state that requires manual repair.

For Exchange or SQL, use Veeam.

Rotate USB drives. Use at least two — ideally three. Alternate them daily. Label each with a day of the week. Keep one offsite at all times. When you connect a fresh drive, take the previous one home or to a second premises. The drive sitting in your car boot is not an elegant solution, but it is an offsite backup that survives a building fire, which is more than most small businesses have.

Veeam Community Edition

Free for up to ten workloads — ten physical servers, virtual machines, or workstations. This is enough for most small businesses with fewer than twenty employees.

Install the Veeam Backup & Replication console on a management machine — not on the server being backed up. The console orchestrates the backups. Deploy Veeam agents to each server and workstation you want to protect. The agents handle the actual backup process — reading disk blocks, compressing data, encrypting the backup file, and sending it to the repository.

Veeam is application-aware. It quiesces Exchange and SQL databases before taking a snapshot, ensuring consistent, restorable backups. It supports incremental backups — after the initial full backup, only the blocks that have changed since the last backup are copied. This is faster, uses less storage, and places less load on the production server.

Configure a daily backup job targeting a local repository — a NAS, a dedicated backup drive, or a separate physical server. Set the retention policy:

This gives you granular recovery for recent events — you can restore to any of the last 14 days — and long-term recovery for older events. If you discover in October that a database was corrupted in June, the monthly backup from May is your recovery point.

Monitor the backup jobs. Veeam sends email notifications for success, warning, and failure. Configure a mailbox to receive these — and read them. A backup job that has been failing silently for three months is a backup job that does not exist. Set a calendar reminder to check backup status weekly if you do not trust yourself to read the emails.

The offsite copy

The offsite copy protects against the disaster that affects the building — fire, flood, theft, and ransomware that reaches every device on the local network, including the NAS.

Cloud storage is the simplest offsite option for small businesses. Backblaze B2 is cost-effective — roughly five dollars per terabyte per month for storage, with egress fees when you download. AWS S3 provides the same function with more granular access controls and integration with other AWS services. Both support versioning — keeping previous versions of each file so that a deletion or overwrite does not destroy the only copy.

Encrypt before upload. Always. Veeam encrypts backup files with AES-256 before transmitting them to the cloud repository. If you use rclone — a command-line tool for syncing files to cloud storage — configure encryption in the rclone remote definition. The encryption key is yours. The cloud provider cannot read your data. An attacker who compromises your cloud storage account without the encryption key obtains encrypted blobs that are computationally useless.

Store the encryption key separately from the backups. Print it. Store it in a safe with the backup codes from your MFA setup. If you encrypt your backups and lose the key, you have destroyed your own backups as effectively as any ransomware.

Do not use OneDrive sync as your backup. Sync is not backup. OneDrive sync mirrors the state of a folder in real time. If ransomware encrypts your files, OneDrive syncs the encrypted versions to the cloud, replacing the clean ones. If someone deletes a file by mistake, the deletion syncs. OneDrive does retain previous versions for a limited period, and it has a "restore your OneDrive" feature — but this is a recovery mechanism, not a backup strategy. It does not provide the retention depth, the immutability, or the tested restorability that a proper backup requires.

The restore test

The step everyone skips. The step that determines whether your backups are real or decorative.

If you have never restored from your backups, you do not have backups. You have files that you hope are backups. Hope is not a recovery strategy. Schedule a quarterly restore test. Not annually. Quarterly. A backup system can fail silently — a misconfigured job, a full disk, a changed permission, a corrupted index — and three months of silent failure means three months of exposure.

File-level test — pick a random file from a week-old backup. Not a file you choose because you know it works. A random file. Restore it to a test location. Open it. Verify it is intact, complete, and uncorrupted. This takes five minutes and confirms the backup chain — the full backup plus all subsequent incrementals — is intact.

Mailbox test — pick a random mailbox from a recent Exchange or M365 backup. Restore it to a test location — not over the production mailbox. Open a few emails. Verify attachments open. Verify calendar items are present. This confirms application-aware backup is working and the Exchange database was captured in a consistent state.

Bare-metal test — once a year, do a full bare-metal restore to a test machine or a virtual machine. Restore the entire server from backup. Boot it. Verify services start. Verify applications function. Verify data is present and consistent. Time the entire process from start to finish.

That time — the actual measured time it takes to restore a server from backup to a functional state — is your real Recovery Time Objective. Not the number you wrote in the incident response plan. Not the number the backup vendor quoted in their marketing materials. The number you measured with a stopwatch. If the measured time is eight hours and your plan says four, your plan is wrong. Update the plan to match reality, or invest in faster recovery to match the plan.

Immutable backups

Ransomware targets backups specifically. This is not speculation — it is standard attacker methodology, documented in post-incident reports from every major incident response firm. The attacker's playbook: compromise the network via phishing or an exposed service, escalate privileges to domain administrator, locate the backup server, delete or encrypt the backup files, wait until the retention period expires so old backups age out, then deploy ransomware to production systems. By the time you see the ransom note, the backups are already gone. The ransom is the only option left, and the attacker knows it.

Immutable storage breaks this playbook.

AWS S3 Object Lock makes backup files undeletable and unmodifiable for a set retention period. Not even the AWS root account can delete them during the lock period. Configure Governance mode for most use cases — it requires special permissions to override the lock, but allows it in emergencies. Configure Compliance mode for regulated data — nobody, including the account owner, can delete the objects until the retention period expires. Set a retention period that matches your backup rotation — 30 days for daily backups, 90 days for monthly backups.

Air-gapped drives achieve the same thing physically. USB drives or removable hard drives that are connected to the backup server only during the backup window and disconnected immediately afterwards. When the drive is not connected, it is not on the network. An attacker who owns your entire network cannot encrypt a drive that is in a drawer in a different building. Rotate at least two drives — one offsite, one connected for the current backup. Swap them on a defined schedule. Label them. Log the rotation.

Veeam's hardened Linux repository provides software-based immutability for on-premises backups. It uses a dedicated Linux server running a minimal installation. Backup files are written with an immutability flag that prevents deletion or modification for a configured retention period. Even root cannot delete them. This is the on-premises equivalent of S3 Object Lock.

At minimum, ensure your offsite copy is immutable. The local copy may be lost to ransomware — that is the failure mode the offsite copy exists to survive.

Documenting the recovery procedure

A written, tested document that answers five questions. This document lives with the incident response plan — printed, in a desk drawer, alongside the MFA backup codes and the emergency contact numbers.

Where are the backups? The physical or logical location of each backup copy. The NAS in the server room — model, IP address, share name. The USB drive in the safe — which safe, where. The S3 bucket — name, region, account.

How do you access them? Credentials, encryption keys, console login details. If the Veeam console is installed on the compromised server, how do you install a fresh console on a clean machine and connect it to the backup repository? Write the steps down. The person recovering the system may not be the person who built it.

What are the credentials? Stored securely — not in a password manager on the compromised system. Not in an email on the compromised email server. Printed, in a sealed envelope, in the same safe as the USB backup drives. Include the cloud storage access key, the encryption passphrase, the Veeam console password, and the repository access credentials.

What is the order of restoration? Not everything at once. Restore in this sequence: Active Directory and DNS first — everything else depends on name resolution and authentication. Then email — communication is the priority. Then file servers — data access. Then line-of-business applications — accounting, CRM, project management. Then workstations — these can be reimaged from standard builds, so they are last.

How long does each step take? Based on your last bare-metal restore test. Not an estimate. Not a hope. The measured duration from the test, plus contingency for the additional stress and confusion of a real incident.

Retention

Legal requirements set the minimum retention period. HMRC requires financial records for six years. Employment records — contracts, payroll, disciplinary records — follow similar timescales. Industry-specific regulations may require longer. If you hold health data, financial services data, or data subject to contractual retention obligations, check the specific requirements.

The breach-discovery problem sets the practical minimum. The average time to discover a data breach exceeds 200 days. Some breaches remain undiscovered for years. If you discover in November that an attacker has been exfiltrating data since March, you need backups from before March — a clean copy to compare against, and a clean state to restore from. Yesterday's backup is contaminated. Last month's backup is contaminated. The backup from February is the one you need, and it only exists if your retention policy keeps monthly backups for at least twelve months.

Keep daily backups for 14 days. Keep weekly backups for 8 weeks. Keep monthly backups for at least 12 months. Keep annual backups for as long as your legal and regulatory obligations require — six years for financial records under HMRC rules.

Cloud service backups

A common assumption: "Our data is in Microsoft 365, so Microsoft backs it up." This is partially true and mostly dangerous. Microsoft guarantees the availability of the service — their infrastructure is redundant, geo-distributed, and resilient. But Microsoft's retention policies for deleted items and mailbox data do not match what most businesses need. Deleted items in Exchange Online are recoverable for 14 days by default, extendable to 30 days. After that, they are gone. SharePoint and OneDrive retain deleted files for 93 days in the recycle bin. After that, gone.

If an attacker silently deletes or modifies data and you discover it four months later, Microsoft's built-in retention may not save you. Third-party backup solutions for M365 — Veeam Backup for Microsoft 365 (free for up to ten users), AvePoint, or Backupify — provide independent backups of Exchange, SharePoint, OneDrive, and Teams data with your own retention policies. They store the backup in your own cloud storage, independent of Microsoft's infrastructure.

The same principle applies to Google Workspace. Google Vault provides archival and eDiscovery but is not a backup tool — it depends on the same infrastructure as the data it archives. Independent backups are independent precisely because they do not share a failure domain with the production data.

The Synnovis case is a study in what happens when backup and recovery are not what the plan assumed. The gap between "we have backups" and "we can recover from backups in the time the business requires" is where organisations fail.

The operational picture

Implement the 3-2-1 rule: three copies of your data, on two different media types, with one copy offsite and immutable. Back up the data the business cannot recreate — financial records, customer data, project files, email, configuration. Use Veeam Community Edition for application-aware backups with 14-day daily, 8-week weekly, and 12-month monthly retention. Send an encrypted offsite copy to Backblaze B2 or AWS S3 with Object Lock enabled. Test restores quarterly — a random file-level restore and a mailbox restore — and perform a full bare-metal restore annually, timing the result. Document the recovery procedure, print it, and store it with the incident response plan in a physical location that does not depend on the systems it describes how to recover. The backup you have not tested is the backup that will fail when you need it.