The backup you'll actually restore.
Borg, Restic, rsync and S3-compatible targets in an EU datacentre — append-only repositories, per-repo keys, and a restore test on the calendar. Because an untested backup is a rumour.
3 copies · 2 media · 1 offsite · 0 assumptions
The thing happens.
Every restore starts with one of these. None of them ask permission.
- ransomwareEncrypts production and, if it can reach them over the same credentials, your backups too.
- rm -rf
rm -rfon the wrong host — a fat-fingered path, a script that assumed a hostname. - hardwareDisk or controller failure. RAID is uptime, not a backup — and it fails too.
- lockoutA provider account lock — a payment dispute, a ToS flag, or a compromised login locks you out of everything in that account, backups included.
- deployA bad deploy at 17:50 on a Friday — the migration that looked fine in staging.
The 3-2-1 Backup Audit
Six questions, live scoring, real arithmetic. All visible at once — no wizard, this isn't that kind of form.
Your loss scenario
- →Move, or add, a copy at a different provider.
- →Schedule a real restore onto a clean host and put it on the calendar.
- →Make the offsite repo append-only or immutable.
- →Add a third independent copy of the data.
How we calculate this
The score is worth 100 points across five factors: copies (20), media (8–15), off-site placement (25), compromise/append-only resistance (20), and restore-test recency (20). The sixth question — downtime tolerance — is not scored; it only measures your pain threshold, so we use it to compare against your realistic recovery time instead.
The 3-2-1 glyphs above light strictly off the literal rule (three or more copies, two or more media, an off-site copy at a different provider) — independent of the weighted score, so you can see which of the three you fail before reading a word.
RPO is fixed at 24h: we don't ask backup frequency, so we assume the most common cadence for this audience — a nightly cron — and disclose that assumption rather than hide it.
RTO comes from your answer to "when did you last restore for real": 4h if this month, 24h if this year, 72h if never, 96h if you can't remember — because a team with a recently-rehearsed playbook recovers faster than one rediscovering its own infrastructure under pressure.
Exposure is (RTO ÷ 24) × your day-rate, plus a manual-rebuild caveat (config, DNS, secrets, tribal knowledge a restore alone doesn't recover) sized the same way as RTO. The day-rate defaults to €500 and is yours to edit.
What a restore actually looks like
Not a slide. The actual sequence, with the honest time each step takes.
- 1
borg list /repo::Confirm the snapshot exists — ~2s
- 2
borg extract --dry-run --list /repo::2026-07-31Verify integrity before touching anything — ~40s for 4.2GB
- 3
borg extract /repo::2026-07-31 var/www var/lib/mysql etcRestore onto a clean host, never the compromised one — 6–40 min depending on size and link
- 4
Compare checksums, restart services, confirm the application actually boots.
- 5
Log the incident timestamp and duration in the restore log — this is what makes the next one faster.
What we run
Bring the tooling you already trust. We host the target, not a proprietary agent.
Borg
Deduplicated, encrypted, incremental. Repositories run append-only over SSH; only our retention job, with a separate key, can prune.
borg extract --dry-run --list ssh://repo::2026-07-31
Restic
Same snapshot model, native S3-compatible backend. The default when you want one tool across disk, SFTP and object storage.
restic -r s3:https://eu.backups.hosting/bucket snapshots
rsync
A plain mirror plus hardlinked daily snapshots — simple, auditable, no proprietary format to get locked into.
rsync -aH --delete --link-dest=../2026-07-30 ./data/ 2026-07-31/
S3-compatible
Standard API — works with Restic, rclone, Velero and anything else that already speaks S3. Object Lock enforces the immutability window at the storage layer.
aws s3api put-object-retention --bucket repo --retention-mode COMPLIANCE
- →EU datacentre — data residency handled, not promised
- →Append-only repos — write-once for the length of the retention window
- →Immutability windows — 14 / 30 / 90-day locks, your choice
- →Per-repo keys — a leaked key opens one repository, not the account
Restore tests, scheduled
Every 30 days we restore a random snapshot from your repository onto a clean, throwaway host — never production — verify checksums, and confirm the application actually starts. You get a one-page report with a timestamp and the engineer's initials. It goes in your compliance folder; we keep a copy too.
The 3-2-1 rule, defined
The 3-2-1 backup rule: keep three copies of your data, on two different types of media, with one copy off-site. It exists because backups fail in clusters — the same disk, the same office, the same account — and each of the three numbers closes one of those clusters on its own.
A backup that has never been restored is not a backup. It's an assumption with a retention policy.
Frequently asked
? What is the 3-2-1 backup rule?
Keep at least three copies of your data, on two different types of media, with at least one copy off-site at a different provider. It is not a suggestion — each number closes a specific failure mode the other two do not cover.
? What's the difference between RPO and RTO?
RPO (Recovery Point Objective) is how much data you can afford to lose, measured backward from the failure — it is set by how often you back up. RTO (Recovery Time Objective) is how long it takes to get back to a working state — it is set by how well-rehearsed your restore actually is.
? What is an append-only or immutable backup repository, and why does it matter?
An append-only repository accepts new snapshots but will not let anyone, including an attacker holding your server's credentials, delete or overwrite old ones during a locked retention window. It is the difference between ransomware encrypting your data, and ransomware encrypting your data and your backups.
? Borg, Restic, or rsync — which should I use?
Borg and Restic both do deduplicated, encrypted, incremental snapshots and support append-only remotes; Restic natively speaks S3-compatible object storage, Borg is faster over SSH with tighter compression. rsync is simpler and fine as a straight mirror, but has no built-in versioning — pair it with hardlink snapshots, or use it as your second medium, not your only one.
? How often should I actually test a restore?
On a calendar, not on faith. Monthly for anything that would hurt if it took a week to rebuild; quarterly at minimum for everything else. A restore you have never run is a rumour with a cron job, not a backup.
? Is S3-compatible storage as reliable as a name-brand cloud provider?
Reliability comes from the storage class, replication and the operator, not the API name. S3-compatible means Restic, rclone and most backup tooling work unmodified against our EU-hosted buckets, so switching, mirroring, or adding a second offsite target is a config change, not a migration project.