Linux server backups in 2026: the 3-2-1 rule, explained with real-world cases

The uncomfortable conversation

Most companies we audit will tell you they "have backups". The trouble starts when we ask three follow-up questions:

• When did you last actually restore from one?
• How long would it take you to bring your website back if the server vanished right now?
• Is your backup sitting on the same server as your database?

The most common answer to the third one is "yes". And that's where the problem hides: if the server goes down, you lose the site and the backup with it.

The 3-2-1 rule in plain English

The 3-2-1 rule isn't new. It's been the de facto standard for decades and it still holds up in 2026 because it solves 95% of real-world disasters:

• 3 copies of your data: the original plus two extra copies.
• On 2 different media: local disk on the server plus external storage, for example. Three folders on the same drive don't count.
• 1 copy off-site: a different datacenter, a different region, a different provider entirely. This is the one that saves you when the server room burns down or your provider goes under.

In 2026, "off-site" usually means an S3 bucket, a Backblaze B2 bucket or a server hosted somewhere else. The technology doesn't matter — what matters is the isolation.

What you actually need to back up

This is where most plans fall apart. A "server backup" means nothing until you spell out what it covers:

The classic mistake is backing up the website and forgetting /etc. The day you need to reinstall, you realise rebuilding nginx, fail2ban, postfix and sudoers by hand costs more than losing the data ever would.

The tools we reach for in 2026

There's no single "best tool" — there's the one that fits your case:

• restic — Encrypted, deduplicated, incremental backups. Native support for S3, B2, Azure, GCS, SFTP and local disk. Our default pick on new projects.
• borgbackup — Similar to restic, with great compression and deduplication. Ideal when the destination is an SSH server with its own storage (rather than a cloud bucket).
• rsnapshot — Veteran, simple, built on rsync and hardlinks. Good for fast copies to a local NAS. No encryption, so trust the destination.
• percona xtrabackup or mariabackup — For large MySQL/MariaDB databases where mysqldump is already taking too long.
• mydumper / myloader — A parallelised mysqldump. Still the most comfortable option for databases up to a few hundred GB.

If your stack runs Docker, add a periodic dump of the volumes (docker run --rm -v vol:/data -v $(pwd):/dest alpine tar czf /dest/vol.tgz /data). Don't assume the container image is enough.

The step almost no one takes: a test restore

A backup you've never restored isn't a backup, it's a hope. We mean this literally: half the time we've opened a backup chain that "had been working for years", we've found one of these:

• Truncated SQL dumps that no one noticed.
• File system permissions blocking half the files.
• Huge files quietly excluded by an old .rsync-filter rule.
• Software version mismatches between source and target.

The bare minimum sanity check: once a quarter, spin up a throwaway server, restore the latest backup, and confirm the website boots and the database is queryable. For business-critical setups, once a month.

Encryption and retention: the two questions nobody asks

Encryption. If your backup travels to an external provider in the clear, you're handing your database to whoever breaks into that account. restic, borg and duplicity encrypt by default; rsnapshot and rsync don't. Store the encryption key somewhere other than the backup itself (your team password manager works).

Retention. Keeping 100 daily backups makes no sense. Keeping a policy like this does:

• 7 daily backups.
• 4 weekly backups.
• 12 monthly backups.
• 2 yearly backups.

That's 25 restore points covering two years, at manageable storage cost. restic and borg do it with a single command (forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 2).

Three real-world cases (anonymised)

Case 1 — The online shop with no off-site backup. A client running a healthy PrestaShop store. Daily backups... on the same VPS, under /home/backups. A disk failure at the provider took the server offline for 18 hours. The backups too. They lost 6 days of orders because the last clean copy was from earlier in the week. We switched them to restic + Backblaze B2 + a monthly restore drill.

Case 2 — The backup that took 14 hours to restore. Server with an 80 GB database. Backups via plain mysqldump. The night of the incident, the restore took the entire night and half of the next morning. We migrated them to mariabackup + restic. Restores dropped to 25 minutes.

Case 3 — The files nobody knew existed. A migration off an old server. The backup we got covered /var/www and /etc/mysql. Missing: a /data/legacy folder with 12 GB of historical PDFs, the Let's Encrypt certificates under /etc/letsencrypt, and a cron job invoked from another machine over SSH. From that day on, we audit the live machine with lsof and find before scoping any backup.

What it costs to do this right

For a typical VPS with website plus a small database:

• restic or borg: free.
• Backblaze B2 or equivalent: around €6 per month per 1 TB stored.
• A properly automated and monitored system: one working day to set up, then cron + email alerts keep it running.

Compared with the cost of losing a week of orders or being down a full day for a major client, it's easily the best cost-to-benefit ratio in your whole infrastructure.

Minimum verification checklist

If you'd rather not read the whole article, here's the actionable summary:

• You have at least 3 copies of your critical data.
• One copy lives off the production server (different provider, different region).
• Your backup includes database, code, /etc, SSH keys and certificates.
• The backup is encrypted if it travels to an external service.
• You have an automated retention policy (daily, weekly, monthly).
• You've restored a test copy within the last 3 months.
• You have alerts if a backup fails (cron alone isn't enough — you need to know).

If you ticked fewer than 5, there's work to do.

Frequently asked questions

Aren't cloud provider snapshots enough? No. Snapshots live in the same account and the same provider. Lose access to that account (unpaid invoice, hack, accidental delete) and they're gone too. They're a useful fast layer, not a single line of defence.

Is RAID a backup? No. RAID protects you from a disk failure, not from an accidental delete, ransomware, an application bug or a human mistake. They solve different problems.

Is git enough for the code? For the code, yes — assuming everything is committed. But it doesn't cover user uploads, the database or system configuration. You still need the complementary piece.

Do I need encryption if the target is my own server in another datacenter? Yes. Encryption is cheap and it protects you if that other server ever ends up in the wrong hands for any reason. There's nothing to lose by encrypting every time.

Wrapping up

Good backups aren't hard, but they do require sitting down for a working day to think through scope, pick tools, automate the job and leave it monitored. The expensive option is not doing it, and finding out on the worst possible day.

If you'd like us to review your infrastructure's backups, find the gaps and leave a 3-2-1 setup running, let's talk, no strings attached.