Backup strategy 3-2-1 for SMEs: restic, rclone, Backblaze B2 and recovery drills (May 2026)

What is this about?

This guide builds a complete 3-2-1 backup strategy for a typical Swiss SME. 3-2-1 means: three copies of the data, on two different media types, one of them offsite (geographically separated). The setup covers three data sources: files on a Linux server (applications, configs, n8n workflows), databases (Postgres, MySQL), and cloud services (Bexio, Office 365, Google Drive).

The stack has four components. restic as a deduplicating, encrypted backup tool for files. mysqldump / pg_dump for database-native consistent snapshots. rclone for cloud-to-cloud backup of Bexio (via API) and Office 365 (via Graph API). Backblaze B2 as a low-cost offsite target with object lock (S3-compatible WORM function) preventing ransomware encryption of backups.

The guide targets three audiences. First: fiduciary or law firm with client data in own application and in Bexio. Second: SME with Bexio + Office 365 + own mail server. Third: developer team with n8n workflows, Postgres and Docker volumes. Budget for the full setup: CHF 30-50/month (10 GB - 1 TB backup volume on Backblaze B2). Setup time: 6-8 hours net, plus one hour monthly for the recovery drill.

Why 3-2-1 and why object lock

The 3-2-1 rule has been backup gold standard for 30 years and has lost no relevance in the ransomware era – quite the opposite. A statistic from the Sophos State-of-Ransomware Report 2025: 76% of SME ransomware incidents also encrypted the primary backup. Anyone backing up only to a NAS at the same site is backing up nothing – the attacker encrypts NAS and server together.

The three lessons: (1) three copies – production + local backup + offsite backup. (2) two different media types – SSD and object storage, or NAS and tape, or local disk and cloud. This protects against media-specific failure modes. (3) one copy offsite – geographically separated, ideally in another data centre, in object-lock mode.

Object lock (S3 standard) is the critical component against ransomware. Even the own admin (or an attacker with admin credentials) cannot delete or overwrite backups during a defined lock period. On Backblaze B2 object lock costs USD 6 per TB per month, with configurable lock period (e.g. 30 days). Without object lock you technically have 3-2-1 but no effective backup against ransomware.

The second point is the weekly full restore. A backup is a backup only when the restore works. Experience from about 30 SME audits: 40% have a backup solution; only 15% of those tested the restore in the last 6 months. Skipping the drill leaves a 50:50 risk that the backup is unusable when needed (corrupted encrypted file, missing database, forgotten volume, wrong restore order). So: every Sunday an automatic restore test into an empty directory plus a quarterly full drill.

How the setup is built

The architecture has four layers: source snapshots, local backup, offsite backup with object lock, monitoring and restore drills.

Source snapshots: before every backup a consistent snapshot is taken. Databases: pg_dump and mysqldump in a maintenance window or with transaction isolation. Docker volumes: docker run --rm -v <volume>:/source restic backup /source, or stop-snapshot-restart. n8n: pg_dump of the n8n Postgres. Filesystem: no snapshot tools needed, restic solves consistency via snapshot IDs.

Local backup: restic creates a deduplicating repository on a second storage volume (ideally different disk, different machine, or NAS). restic encrypts with AES-256 client-side – the repository on storage is invisibly closed on the server side. The first backup takes long (TBs of data), incremental backups are small (10-100 MB per day with normal change rate).

Offsite backup with object lock: rclone syncs the restic repository to Backblaze B2. B2 is S3-compatible and offers object lock in "compliance" mode (even the account owner cannot delete during the lock period). Lock period 30 days = 30 days of protection against ransomware encryption of backups. Cost: USD 0.006 per GB per month plus USD 0.01 per GB download (on restore). At 100 GB backup volume: USD 0.60/month storage, on restore USD 1 for download.

Cloud-to-cloud backup: Bexio has no native export API for full backup, but the REST API allows a full export via script: download /2.0/contact, /2.0/kb_invoice, /2.0/accounting/journal etc. to JSON files, push into the restic repository. Office 365: Graph API with Exchange Online backup permission – export mailboxes as PST files, OneDrive files via rclone. These cloud snapshots join the backup daily.

Monitoring and Telegram notification: each backup script writes a JSON status file with timestamp, size, duration, errors. A cron job at 8 AM daily checks the status file and sends a Telegram message to the IT lead on errors (or missing status). Plus a Grafana dashboard with trends over weeks and months.

Restore drills: two levels. Weekly automatic restore test: a cron job pulls a random file from the backup every Sunday, compares hash against production, writes success/failure to the status file. Quarterly full drill: manually restore a test machine from the backups, including database restore and application start. Quarterly drill takes 4-8 hours but is the only guarantee that the backup will work in a real incident.

Backup setup in 11 steps

1. 01Step 1 – Backblaze B2 account and bucket: at backblaze.com create an account. Create bucket "kmu-backups", region "eu-central-003" (Amsterdam) – closer to CH than US West. Bucket settings: enable "Object Lock" with default retention 30 days in compliance mode. Generate an application key with bucket-scoped permissions.
2. 02Step 2 – install restic: on the server `apt install restic` (Debian/Ubuntu) or `brew install restic` (Mac). Check: `restic version` (expect 0.17+ or newer, May 2026 stable).
3. 03Step 3 – initialise restic repository: generate password securely `openssl rand -base64 32 > /etc/restic-password`, `chmod 600 /etc/restic-password`. Store the backup password SEPARATELY in a password manager (1Password, Bitwarden). Local repository: `restic -r /mnt/backup-disk/repo init --password-file /etc/restic-password`.
4. 04Step 4 – install and configure rclone: `curl https://rclone.org/install.sh | sudo bash`. `rclone config` → New remote → "b2" → name "b2backup" → enter account ID and application key from step 1. Check: `rclone lsd b2backup:`.
5. 05Step 5 – database backup script: `/opt/backup/db-backup.sh`: `#!/bin/bash; DATE=$(date +%Y%m%d-%H%M); pg_dump -U postgres -F c -f /tmp/pg-$DATE.dump main_db; mysqldump --single-transaction --routines bexio_mirror > /tmp/mysql-$DATE.sql; restic -r /mnt/backup-disk/repo backup --password-file /etc/restic-password --tag db /tmp/pg-$DATE.dump /tmp/mysql-$DATE.sql; rm /tmp/pg-$DATE.dump /tmp/mysql-$DATE.sql`. Make executable.
6. 06Step 6 – files backup script: `/opt/backup/files-backup.sh`: `#!/bin/bash; restic -r /mnt/backup-disk/repo backup --password-file /etc/restic-password --tag files --exclude="node_modules" --exclude="*.log" /var/lib/n8n /var/www /etc /home/work`. Make executable.
7. 07Step 7 – cloud backup script Bexio: Python script `/opt/backup/bexio-export.py` with Bexio API token: GET /2.0/contact, /2.0/kb_invoice, /2.0/accounting/journal as JSON. Then: `restic backup --tag bexio /var/backups/bexio/`. Cron 1x daily.
8. 08Step 8 – Office 365 backup: configure rclone backend "onedrive" via OAuth flow. Cron script: `rclone sync onedrive:Documents /var/backups/o365/documents`, then restic backup as above.
9. 09Step 9 – offsite sync to B2: script `/opt/backup/offsite-sync.sh`: `#!/bin/bash; rclone sync /mnt/backup-disk/repo b2backup:kmu-backups --b2-versions --progress`. Object lock on the B2 bucket protects the versions. Cron 1x daily after local backups (e.g. 03:00).
10. 10Step 10 – cron and Telegram notification: in /etc/cron.d/backup: `0 1 * * * root /opt/backup/db-backup.sh && /opt/backup/files-backup.sh && /opt/backup/offsite-sync.sh 2>&1 | tee /var/log/backup-$(date +\%F).log`. Telegram script checks the log file for "error|fail" and pushes to admin on a match.
11. 11Step 11 – weekly restore drill: `/opt/backup/restore-test.sh`: `#!/bin/bash; SNAP=$(restic -r /mnt/backup-disk/repo --password-file /etc/restic-password snapshots --json | jq -r ".[-1].id"); restic -r /mnt/backup-disk/repo --password-file /etc/restic-password restore $SNAP --target /tmp/restore-test --include /etc/hostname; diff /etc/hostname /tmp/restore-test/etc/hostname && echo OK || echo FAIL`. Cron on Sundays. Quarterly: full manual, spin up a test VM, full restore, app start.

When this strategy fits

This 3-2-1 strategy fits practically every SME with its own IT systems. Specifically: (a) every fiduciary with client data in its own database, (b) every law firm with documents in SharePoint/Office 365, (c) every SME with Bexio plus a custom application, (d) every dev team with its own server, Postgres and n8n workflows.

The strategy scales from a few GB to several TB without changes. At very large volumes (> 10 TB), specialised solutions like Veeam or Rubrik pay off – but that is enterprise territory. For SMEs up to 5 TB the restic+rclone+B2 stack is the pragmatic standard with annual licence cost below CHF 600 (Backblaze B2 for 5 TB).

For single-file local applications without cloud touch (e.g. only Excel files on a notebook), the full strategy is overkill – a Dropbox/OneDrive sync with version history plus a manual quarterly copy to an external SSD is enough. As soon as 2+ data sources or multi-user applications are involved, the professional stack pays off.

When this strategy is not the fit

This strategy does not fit when (a) the responsible person has no Linux/cron background – then a commercial solution like Synology Hyper Backup or Veeam Backup for Microsoft 365 with GUI is the better choice. (b) data has extremely high compliance requirements (FINMA-regulated banks, healthcare) – then specialised solutions with audit reports. (c) backup volume is so small (< 5 GB) that setup time outweighs the benefit – then a simple cloud sync.

More pitfalls: not activating object lock – ransomware can encrypt the backup along with everything else. Storing the restic password in the same repository – repository without password is unusable, on loss backup lost. Storing the restic password only on the server – when the server is lost no one can reach the backup. Backup script without an error handler – silent failure is the most common backup tragedy.

Trade-offs

FAQ

Related topics

Sources

1. restic – fast, secure, efficient backup program · 2026-05
2. rclone documentation – sync to/from cloud storage · 2026-05
3. Backblaze B2 – Object Lock for ransomware protection · 2026-04
4. Sophos State of Ransomware Report 2025 · 2026-03
5. NIST SP 800-209 – Security Guidelines for Storage Infrastructure · 2026-02