{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihqjvibvw6hhnnxjiahhvcrstw7fsg27tlqmhj7azkmqeojaltel4",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3moxxbodfdpi2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreic2jrqewjmrb4esmhvaev6tme4x4ccsstjon77jr5xfwnbs25hsra"
    },
    "mimeType": "image/webp",
    "size": 67374
  },
  "path": "/byte-guard/the-3-2-1-backup-setup-for-self-hosters-restic-backblaze-b2-2mpb",
  "publishedAt": "2026-06-23T17:19:50.000Z",
  "site": "https://dev.to",
  "tags": [
    "selfhosting",
    "backups",
    "restic",
    "docker",
    "byte-guard.net",
    "3-2-1 rule",
    "build-from-scratch VPS guide",
    "Harden Your Linux VPS in 10 Minutes",
    "Backblaze B2",
    "GitHub releases",
    "here's how I self-host Vaultwarden",
    "your Uptime Kuma setup",
    "VPS setup page",
    "Docker security guide"
  ],
  "textContent": "_Originally published on byte-guard.net._\n\n> **TL;DR:** A real backup is encrypted, off-site, and restore-tested. The fastest way to get all three on a self-hosted server is **restic** pushing deduplicated, client-side-encrypted snapshots to **Backblaze B2** — roughly $6/TB/month. This guide wires up the 3-2-1 rule end to end: what to back up in a Docker stack, an append-only key that survives ransomware, automation with a systemd timer, monitoring, and the restore drill almost nobody actually runs.\n\nEvery self-hoster has the same near-miss story. A `docker compose down -v` that took the `-v` flag too literally. A disk that filled and corrupted a SQLite database. A VPS the provider \"migrated\" into a coma. You only find out whether you had a backup at the exact moment you desperately need one — and for most people the answer is _no, not really_.\n\nThe uncomfortable truth: copying a folder to a second disk is not a backup. **A backup is encrypted, lives somewhere your server can't reach, and has been restored at least once to prove it works.** That's the 3-2-1 rule — **3** copies of your data, on **2** different media, with **1** off-site — and it's the difference between a bad afternoon and a rebuilt-from-memory weekend.\n\nIn this guide I'll set up the backup system I actually run: restic pushing encrypted snapshots to Backblaze B2, automated on a timer, monitored, and — the part everyone skips — verified with a real restore. It works the same on a €5 VPS or a home-lab box.\n\n##  Prerequisites\n\n  * A **self-hosted server** with the data you care about — Docker volumes, config files, databases. If you don't have one yet, my build-from-scratch VPS guide gets you there.\n  * **A hardened host.** Backups contain everything sensitive you own; run through Harden Your Linux VPS in 10 Minutes first.\n  * **A Backblaze B2 account.** The free tier gives you 10 GB; beyond that it's about $6/TB/month with no egress fee for restores up to 3× your stored amount. Any S3-compatible target works (Wasabi, Cloudflare R2, even another VPS) — B2 is just the cheapest sane default.\n  * **Root or sudo** on the server.\n\n\n\n##  Why restic (and not tar + cron)\n\nA shell script that tars a directory and uploads it is better than nothing, but it has three problems restic solves for free:\n\n  * **Deduplication.** restic splits files into content-addressed chunks. The second snapshot of a 5 GB database that changed by 50 MB uploads ~50 MB, not 5 GB. Daily backups stay cheap.\n  * **Client-side encryption.** Everything is AES-encrypted _before_ it leaves your server. Backblaze stores ciphertext it can't read. Your data is private even if the bucket leaks.\n  * **Snapshots, not overwrites.** Each backup is a point-in-time snapshot you can browse and mount. Ransomware that encrypts today's files doesn't touch yesterday's snapshot.\n\n\n\nIt's a single static Go binary with no daemon. That's the whole appeal.\n\n##  Step 1: Install restic\n\n\n    sudo apt update && sudo apt install -y restic\n    restic version    # want 0.16+ for the modern compression\n\n\nIf your distro ships an old version, grab the static binary from the GitHub releases and drop it in `/usr/local/bin/`. Then let it self-update: `sudo restic self-update`.\n\n##  Step 2: Create the Backblaze B2 bucket and key\n\nIn the Backblaze console:\n\n  1. **Create a bucket** — name it something like `yourname-restic`, set it **Private** , and turn on **Object Lock** if offered (we'll use it for ransomware protection below).\n  2. Go to **Application Keys → Add a New Application Key**. Scope it to _just this bucket_. Backblaze shows you a `keyID` and `applicationKey` **once** — copy both now.\n\n\n\nDrop the credentials into an environment file the backup will source, and lock its permissions hard:\n\n\n\n    sudo mkdir -p /etc/restic\n    sudo tee /etc/restic/b2.env >/dev/null <<'EOF'\n    export B2_ACCOUNT_ID=\"your_keyID\"\n    export B2_ACCOUNT_KEY=\"your_applicationKey\"\n    export RESTIC_REPOSITORY=\"b2:yourname-restic:server1\"\n    export RESTIC_PASSWORD=\"a-long-random-passphrase-you-will-back-up-separately\"\n    EOF\n    sudo chmod 600 /etc/restic/b2.env\n\n\n> **Critical:** that `RESTIC_PASSWORD` is the encryption key for your entire backup. If you lose it, your snapshots are unrecoverable ciphertext — there is no reset. Store a copy somewhere off this server: a password manager works perfectly, and here's how I self-host Vaultwarden for exactly this kind of secret.\n\n##  Step 3: Initialize the repository\n\n\n    source /etc/restic/b2.env\n    restic init\n\n\nYou'll see `created restic repository ... at b2:yourname-restic:server1`. That's the encrypted repo living off-site. Everything from here pushes into it.\n\n##  Step 4: What to actually back up in a Docker stack\n\nThis is where most guides wave their hands. On a typical self-hosted box, the data that matters lives in three places:\n\n  * **Named Docker volumes** — your databases, app state, uploaded files (n8n's `n8n_data`, Nextcloud's data volume, Vaultwarden's `bw-data`).\n  * **Compose files and`.env`** — the configuration that defines the stack, usually under `/opt`.\n  * **Reverse-proxy and host config** — Nginx Proxy Manager data, `/etc` bits you've customized.\n\n\n\nThe mistake is backing up a _running_ database's files directly — you can capture it mid-write and get a corrupt copy. For SQLite-backed apps (Vaultwarden, n8n, Ghost) the clean pattern is: dump, then back up the dump. Here's a wrapper that stops nothing, dumps databases consistently, and snapshots the volumes:\n\n\n\n    #!/usr/bin/env bash\n    # /etc/restic/backup.sh\n    set -euo pipefail\n    source /etc/restic/b2.env\n\n    STAGE=/var/backups/restic-stage\n    mkdir -p \"$STAGE\"\n\n    # Example: consistent SQLite dump (Vaultwarden). Repeat per app.\n    docker exec vaultwarden sqlite3 /data/db.sqlite3 \".backup '/data/db.backup.sqlite3'\" || true\n    docker cp vaultwarden:/data/db.backup.sqlite3 \"$STAGE/vaultwarden.sqlite3\"\n\n    # Back up live config dirs + the staged dumps in one snapshot\n    restic backup \\\n      /opt \\\n      /etc/restic \\\n      \"$STAGE\" \\\n      --tag automated \\\n      --exclude-caches \\\n      --exclude '*.log'\n\n    # Retention: keep 7 daily, 4 weekly, 6 monthly; prune the rest\n    restic forget --tag automated \\\n      --keep-daily 7 --keep-weekly 4 --keep-monthly 6 \\\n      --prune\n\n    rm -rf \"$STAGE\"\n\n\n\n    sudo chmod 700 /etc/restic/backup.sh\n\n\nFor Postgres or MySQL containers, swap the dump line for `docker exec db pg_dump -U user dbname > \"$STAGE/db.sql\"`. The principle holds: **dump the database to a flat file, then let restic snapshot the file.**\n\n##  Step 5: Automate it with a systemd timer\n\nCron works, but a systemd timer gives you logs, failure status, and `Persistent=true` so a missed run (server was off) fires on next boot. Create two files:\n\n\n\n    # /etc/systemd/system/restic-backup.service\n    [Unit]\n    Description=restic backup to Backblaze B2\n    After=network-online.target docker.service\n\n    [Service]\n    Type=oneshot\n    ExecStart=/etc/restic/backup.sh\n\n\n\n    # /etc/systemd/system/restic-backup.timer\n    [Unit]\n    Description=Run restic backup nightly\n\n    [Timer]\n    OnCalendar=*-*-* 03:00:00\n    Persistent=true\n\n    [Install]\n    WantedBy=timers.target\n\n\nEnable and test it:\n\n\n\n    sudo systemctl daemon-reload\n    sudo systemctl enable --now restic-backup.timer\n    sudo systemctl start restic-backup.service   # run once now\n    journalctl -u restic-backup.service -n 40     # read the result\n\n\nCheck `systemctl list-timers restic-backup.timer` to confirm the next run time.\n\n##  Step 6: The restore drill (do this now, not in a crisis)\n\n**An untested backup is a hope, not a backup.** Run a restore _today_ , while nothing is on fire, so you know the muscle memory and you know it works.\n\nList your snapshots:\n\n\n\n    source /etc/restic/b2.env\n    restic snapshots\n\n\nRestore the latest snapshot into a scratch directory and eyeball it:\n\n\n\n    restic restore latest --target /tmp/restore-test\n    ls -R /tmp/restore-test | head\n\n\nEven better, **mount** the repo like a filesystem and browse it:\n\n\n\n    mkdir /tmp/restic-mnt\n    restic mount /tmp/restic-mnt    # Ctrl-C to unmount\n    # in another shell: cd /tmp/restic-mnt/snapshots/latest\n\n\nIf your staged database dump and `/opt` configs are sitting there intact, you have a real, recoverable backup. Put a reminder in your calendar to repeat this restore test quarterly.\n\n##  Ransomware-proofing: append-only keys\n\nHere's the failure mode people miss: if your server is fully compromised, the attacker has your B2 credentials too — and can simply _delete every backup_ before encrypting your live data. Two defenses:\n\n  * **An append-only application key.** Create a second B2 key restricted from deletes, and use it on the server. Run `restic forget --prune` from a _separate trusted machine_ with the full-access key. The server can write new snapshots but can never erase old ones.\n  * **Object Lock / immutability.** If you enabled Object Lock on the bucket (Step 2), snapshots are write-once for a retention window even an admin can't override. This is the strongest protection and worth the few minutes to configure.\n\n\n\nFor a single-server setup, the append-only key is the high-value move: it means a root compromise still can't destroy your history.\n\n##  Monitor it so silent failure can't bite you\n\nA backup job that quietly stopped running three weeks ago is worse than no backup, because you _think_ you're covered. Wire the job to a dead-man's-switch:\n\n\n\n    # at the end of backup.sh, ping a healthcheck URL on success\n    curl -fsS -m 10 https://your-uptime-kuma/api/push/XXXX?status=up >/dev/null\n\n\nPoint that at a push monitor in your Uptime Kuma setup configured to alert you if it _doesn't_ hear from the job within 25 hours. Now a failed or skipped backup pages you instead of rotting in silence.\n\n##  Troubleshooting\n\n**`restic init` hangs or returns a 401.**\nCause: wrong B2 key or it's scoped to a different bucket. Fix: regenerate the application key, confirm `RESTIC_REPOSITORY` matches `b2:<bucket>:<path>` exactly, re-`source` the env file.\n\n**Backups are huge every night despite dedup.**\nCause: you're backing up a live database file that rewrites entirely, or log files that churn. Fix: dump databases to a flat file (Step 4) and `--exclude '*.log'`.\n\n**`repository is already locked`.**\nCause: a previous run died mid-backup. Fix: `restic unlock` (safe when you're sure nothing else is running), then retry.\n\n**Restore is slow.**\nCause: B2 download throughput plus restic reassembling chunks. Fix: it's normal — restores read a lot of small blobs. For a full disaster restore, pull to a box with good bandwidth. This is exactly why you test _before_ the emergency.\n\n##  Conclusion\n\nYou now have backups that actually qualify as backups: encrypted before they leave the box, deduplicated so daily snapshots stay cheap, pushed off-site to Backblaze B2, automated on a timer, ransomware-resistant via an append-only key, monitored by a dead-man's switch, and — most importantly — restore-tested. That's the full 3-2-1 rule, not a folder copy you're hoping works.\n\nSet it up once and the only ongoing cost is a few dollars a month and a quarterly restore drill. The next time a `down -v` or a dying disk takes out your stack, it's a thirty-minute restore instead of a rebuild from memory.\n\nIf you'd rather not wire all this up yourself, **that's part of the VPS setup service I offer** — I'll harden a server and stand up your stack (Vaultwarden, n8n, Nextcloud) _with_ backups configured, for a flat $49 on infrastructure you own. Details on the VPS setup page. Otherwise, the Docker security guide is the natural next read to shrink the attack surface you're backing up in the first place.\n\n##  Try the services\n\n  * Backblaze B2 — ~$6/TB/month, S3-compatible, the off-site target in this guide. No affiliate link (not a partner yet).\n  * restic — free, open source, single binary. The whole engine.\n\n\n\n##  Affiliate disclosure\n\nNo affiliate links in this post — Backblaze B2 and restic are tools I pay for and run myself. The $49 VPS setup is my own paid service. — _enim_",
  "title": "The 3-2-1 Backup Setup for Self-Hosters: restic + Backblaze B2"
}