TL;DR: The 3-2-1 rule means 3 copies of your data, on 2 different media types, with 1 offsite. In the modern version (3-2-1-1-0), you add 1 immutable copy and 0 verification errors. This article shows how to apply this concretely in a 20-person SMB with open-source tools, a realistic budget, and real examples.
We have a backup. Somewhere. There's the USB key in the accountant's desk drawer. The Dropbox that syncs everyone's files (or almost). The "yeah yeah, the server is backed up" that someone confirmed two years ago without anyone really knowing how.
And then one day, ransomware hits. Or the hard drive dies. Or an employee deletes the wrong folder on a Friday at 4:45 PM. And then the killer question: how long has it been since we last tested a restore?
If the answer makes you uncomfortable, you're in exactly the right place.
The 3-2-1 rule in 30 seconds
The concept dates back to the 2000s, popularized by photographer Peter Krogh. It's simple:
3 copies of your data (the original + 2 backups).
2 different media types (e.g.: local disk + cloud storage).
1 offsite copy (not in the same building).
The idea is that no single incident can destroy everything. A fire burns down your office? The cloud copy is intact. Ransomware encrypts your server? The disconnected external drive is untouched. The logic is brutally simple, and that's why it works.
The modern version: 3-2-1-1-0
In recent years, ransomware has changed the game. Modern attacks specifically target backups: if the malware can encrypt your backups at the same time as your production data, you've got nothing left.
Hence the 3-2-1-1-0 extension:
1 immutable or disconnected (air-gapped) copy. A backup that nobody can modify or delete, even with administrator access.
0 verification errors. Every backup is tested automatically. No more "let's hope it works".
This is the standard we recommend in 2026. The basic 3-2-1 version is still an excellent starting point, but if you want to sleep soundly against ransomware, the additional 1-0 makes all the difference.
A concrete case: 20-person SMB
Let's take a realistic example. Your 20-employee SMB uses:
An Odoo server: your ERP, with the PostgreSQL database and filestore (attached documents, accounting records).
A Nextcloud: your shared files, roughly 500 GB of documents.
20 workstations: employee laptops with local files.
Email: hosted somewhere (Microsoft 365, Google Workspace, or your own server).
Here's how the 3-2-1-1-0 rule applies to each one:
The Odoo server
This is the heart of your business. If Odoo goes down and the data is lost, we're talking invoices, purchase orders, client contacts, accounting history: a catastrophe.
Copy 1 (local): an automated script runs a PostgreSQL dump every night at 2 AM, plus a copy of the filestore. Everything is stored on a storage volume separate from the production server.
Copy 2 (other server): BorgBackup or Restic pushes an encrypted backup to a second server in another data center. Deduplicated, so only daily changes are transferred.
Copy 3 (immutable cloud): a weekly copy is sent to object storage (Backblaze B2 or Wasabi) with object lock enabled. Even if someone gets your credentials, it's impossible to delete backups before the retention period expires.
Nextcloud
500 GB of shared files — that's your team's daily life. Contracts, proposals, HR documents, it's all there.
Copy 1 (on the server): files live on the Nextcloud server itself (with versioning enabled in Nextcloud to recover accidental deletions).
Copy 2 (local backup): Restic runs a daily incremental backup to a local NAS or separate volume. The first backup is large, subsequent ones only capture the differences.
Copy 3 (offsite): the same Restic backup is replicated to remote object storage, encrypted and immutable.
The advantage of Restic here: it natively supports the S3 protocol, so sending to Backblaze B2 or Wasabi is configured in a single line.
Workstations
Let's be honest: the best strategy for workstations is to store nothing on them. If all your work files are on Nextcloud and your ERP is in Odoo, an employee's laptop can catch fire without the company losing a single piece of data.
For files that still end up locally (it always happens), the Nextcloud sync client acts as a real-time backup to the server. And the server itself is backed up according to the strategy above.
For critical workstations (management, accounting), you can add a tool like Duplicati that runs automatic backups to the cloud.
This is the big blind spot of backup strategies. "It's at Microsoft, it's safe." No. Microsoft 365 and Google Workspace don't back up your emails the way you think they do. Their infrastructure is resilient, but if an employee deletes emails or an account is compromised, recovery is limited in both time and options.
A third-party backup solution (several compatible ones exist) makes a daily copy of all mailboxes to storage you control. It's one of the most underestimated IT investments.
To learn more: Why back up your Google data.
The open-source tools to get there
| Tool | Type | Strengths | Limitations | Best for |
|---|---|---|---|---|
| BorgBackup | Deduplication + compression | Excellent deduplication, low memory usage, "borg mount" command to browse backups | No native S3 support (requires rclone or borgmatic), works best locally/SSH | Servers with local or remote SSH storage |
| Restic | Deduplication + encryption | Native S3/B2/Azure/GCS support, fast backups, flexible restores | Higher memory usage, no compression before v0.16 | Mixed environments, cloud storage |
| Duplicati | GUI + cloud | User-friendly web interface, supports 25+ backends, built-in scheduling | Less performant on large volumes, interface sometimes unstable | Workstations, non-technical users |
| rsync | File synchronization | Simple, installed everywhere, efficient differential transfers | No built-in encryption, no deduplication, no versioning | Simple mirror copies between servers |
For a typical SMB, our preferred combination is Restic + S3 object storage. The native S3 protocol support massively simplifies the configuration, encryption is built in by default, and deduplication keeps storage costs reasonable.
Where to store offsite copies
Several options, depending on your budget and requirements:
Cloud object storage (Backblaze B2, Wasabi): the most popular choice for SMBs. Backblaze B2 costs about 6 USD/TB/month with free egress up to 3x the stored volume. Wasabi is 6.99 USD/TB/month with free egress as long as it stays less than or equal to the stored volume (1:1 ratio), a 90-day minimum retention period, and a 1 TB billing minimum. For 1 TB of backups, that's 72 to 84 USD per year.
Second data center: a small dedicated server or VPS in another datacenter, ideally in another region. More control, but more management.
Physical rotation: an external hard drive taken offsite every week. It sounds archaic, but it's a perfect air gap. The downside is that the latest copy can be up to a week behind.
The decisive factor: where is the data physically located? For a Quebec-based SMB, making sure backups stay in Canada (ideally in Quebec) simplifies compliance with Law 25. Backblaze has a datacenter in Toronto, and several Quebec-based providers offer S3-compatible object storage.
Encryption: non-negotiable
An unencrypted backup that leaves your premises is a data breach waiting to happen. Period.
Restic systematically encrypts in AES-256 (cannot be disabled), and BorgBackup requires choosing an encryption mode when initializing the repository (the recommended mode, repokey, uses AES-256). That's one of the reasons we recommend them: encryption isn't a forgotten checkbox sitting in a corner. Your data is unreadable without the key, whether on the local disk, in transit, or in the cloud.
The critical point: key management. If you lose the encryption key, your backups are just as useless as having no backups at all. Store encryption keys separately from the backups themselves (an enterprise password manager, a physical safe, or both).
To dive deeper into encryption: Zero Trust, Zero Knowledge, and end-to-end encryption.
Testing restores (the part nobody does)
Let's face it: a backup that's never been tested isn't a backup. It's a file taking up disk space and giving you a false sense of security.
The restore test should be:
Automated: a monthly script that restores the latest backup in a test environment and verifies the database opens correctly.
Documented: the complete restore procedure is written, tested, and accessible to more than one person on the team.
Timed: you know how long it takes to restore each system. Because one day, your CEO is going to ask "how long will it take?" and "no idea" isn't the right answer.
A good monthly test for an SMB: restore the Odoo PostgreSQL dump on a test server and verify you can log in and browse around. It takes 30 minutes to automate and it can save your business.
Retention policies: how long to keep
Keeping every backup since the dawn of time is expensive and pointless. Grandfather/father/son (GFS) rotation is the standard:
Daily (son): keep the last 7 days.
Weekly (father): keep the last 4 weeks.
Monthly (grandfather): keep the last 12 months.
Annual: keep 1 per year for 3 to 7 years (depending on your industry and legal obligations).
Result: instead of 365 backups per year, you keep about 24. Your storage costs stay predictable, and you can go back in time to recover a file deleted six months ago.
Restic and Borg natively support retention policies. A single restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 3 command does the cleanup automatically.
Automation and monitoring
Manual backups never last. Someone forgets, goes on vacation, changes positions. Automation isn't a luxury — it's the only way it works long-term.
The minimum viable setup:
Scheduled tasks (cron): every backup runs automatically, every night, without human intervention.
Post-backup verification: the script verifies the backup completed correctly (exit code, file size, integrity).
Failure alerts: if a backup fails, an email or notification is sent immediately. Not in a log that nobody reads.
Dashboard: a centralized place to see the status of all backups at a glance.
Tools like Healthchecks.io (open-source, self-hostable) let you monitor that your cron jobs are running. If the backup doesn't ping the service within the expected timeframe, you get an alert.
What it actually costs
Here's a realistic estimate for our 20-person SMB:
| Component | Solution | Estimated monthly cost |
|---|---|---|
| Cloud storage (1 TB) | Backblaze B2 | ~$8 CAD |
| Remote backup server | VPS with 500 GB storage | ~$25 CAD |
| Backup software | Restic / BorgBackup (open-source) | $0 CAD |
| Monitoring | Self-hosted Healthchecks.io | $0 CAD |
| Initial setup | Implementation by a technician | ~$500-1,500 CAD (one-time) |
| Recurring total | ~$33 CAD/month |
$33 a month to protect all your company's critical data. Compare that to the cost of a full day of downtime: salaries paid with no production, clients not served, orders lost. The math is pretty straightforward.
Classic mistakes (we see them every week)
Backing up to the same server: your backup is on the same disk as the production data. The disk dies, you lose everything. Twice.
Confusing sync with backup: Dropbox, Google Drive, and OneDrive sync your files. If ransomware encrypts your local files, the sync happily pushes the encrypted files to the cloud. That's not a backup — it's a mirror.
No encryption: the external backup drive is unencrypted. It gets stolen in a break-in (yes, it happens). Congratulations, that's now a data breach you have to report under Law 25.
Zero restore tests: "we have backups!" Really? When's the last time you tried to restore? "Uh..." Exactly.
No monitoring: the cron job silently crashed three months ago. Nobody noticed. Your most recent backups are from last quarter.
Only one person knows how to restore: and they're on vacation when disaster strikes. Documenting the procedure is just as important as the backup itself.
What 3-2-1 doesn't solve
We're not going to pretend the 3-2-1 rule solves everything:
It doesn't protect against silent corruption. If your data gets corrupted and you don't notice for two months, all your recent backups contain the same corruption. Long-term retention (GFS) helps, but it doesn't replace active integrity monitoring.
It requires discipline. The initial setup is 20% of the work. The remaining 80% is ongoing maintenance: monitoring alerts, testing restores, adjusting when infrastructure changes.
Open-source tools require technical expertise. Restic and Borg are powerful but operate from the command line. If nobody on your team is comfortable with a terminal, you'll need to either train someone or outsource the management to a provider.
Cost scales with volume. At 1 TB, it's very affordable. At 10 TB, cloud storage costs start to add up and you need to optimize (aggressive deduplication, shorter retention, compression).
Minimum backup checklist for an SMB:
- Every critical system has at least 3 copies of its data
- At least one copy is offsite (cloud or another datacenter)
- At least one copy is immutable or disconnected
- All backups are encrypted (AES-256)
- Encryption keys are stored separately from backups
- A restore test is done every month
- Backup failures trigger an immediate alert
- The restore procedure is documented and known by at least 2 people
How we do it
At Blue Fox, we implement 3-2-1-1-0 backup strategies based on open-source tools. We prefer Restic for its versatility and native object storage support, combined with BorgBackup for cases where deduplication and memory efficiency take priority.
We automate everything: backups, integrity checks, alerts, and we integrate monitoring into our management platform so nothing slips through the cracks. And above all, we test restores. Regularly. For real.
Want us to take a look at your current backup strategy? We do a quick assessment and tell you what's missing (and what's already working). Let's talk.
The bottom line
The 3-2-1 rule isn't complicated and it isn't expensive. For about $33 a month and a reasonable initial investment, a 20-person SMB can protect all its critical data against pretty much every common disaster scenario.
The hardest part isn't the technology. It's actually doing it, doing it for real, and keeping at it. Every month. No exceptions.
Your next step? Open your last backup and try restoring a file. If it works: congrats, you're already ahead of most people. If it doesn't: let's talk.
Sources
Backblaze: The 3-2-1 Backup Strategy
Veeam: 3-2-1 Backup Rule
BorgBackup: official documentation
Restic: official documentation
Backblaze B2: pricing
Wasabi: pricing