Permalink I saw Chris's post, The Grand Blog Reunification (opens in a new tab), where he explains that his cloud sync was silently failing and he wiped his computer without realizing he didn't have a backup. Oops. Not wanting to repeat that type of issue, I decided to revisit my own backup strategy. Back in 2022, I wrote about how I used my NAS and rsync to back up my computer. This is how I'm backing up my computer in 2026. My goal is the classic 3-2-1 backup strategy. 3 – Keep 3 copies of any important file: 1 primary and 2 backups. 2 – Keep the files on 2 different media types to protect against different types of hazards. 1 – Store 1 copy offsite (e.g., outside your home or business facility). — CISA, Data Backup Options (opens in a new tab) Without further ado, here is how I check the boxes on that goal. The tool # I use borg (opens in a new tab), with borgmatic (opens in a new tab). Borg does the actual work: deduplicated, compressed, encrypted, versioned backups. Borgmatic is a YAML wrapper on top of it. I configure it once and then I get to stop thinking about it, which is exactly what I want out of a backup tool. That versioning bit is why I left rsync behind. My 2022 setup mirrored my home directory to the NAS, and a mirror isn't a backup. If I deleted a file or corrupted it, the next rsync run would happily copy that damage right over the good copy. Borg keeps history. A mistake is recoverable instead of replicated. I run two borgmatic configs, one per destination. Copy 1: the laptop # The primary is my 2015 MacBook Pro running Debian 13. Copy 1, check. Copy 2: the NAS # My Synology DS220+ with two drives in RAID 1. Same box from the 2022 post, still chugging along. It's a different medium from the laptop's internal SSD, which covers the 2 in 3-2-1. repositories: - path: ssh://borg@192.168.1.22/./backups/laptop ssh_command: ssh -i /home/obsolete29/.ssh/id_ed25519 -o IdentitiesOnly=yes -p 2222 It backs up hourly. I've got 40 archives sitting there right now, going back to March. Copy 3: BorgBase, offsite # BorgBase (opens in a new tab) is hosted borg storage. This is the 1 in 3-2-1, the copy that survives the house. repositories: - path: ssh://<repo-id>@<repo-id>.repo.borgbase.com/./repo Every 6 hours, 22 archives. Both repos are encrypted, so BorgBase is storing ciphertext. They can't read my files. Nice. 👌🏻 What this costs # Three copies of everything sounds expensive. It isn't, and that's down to deduplication. NAS Offsite Original size 1.01 TB 507.30 GB Compressed 922.71 GB 465.32 GB Deduplicated 26.74 GB 25.74 GB That's a terabyte of archive history living in 27 GB of actual disk. Borg stores each unique chunk once, so 40 snapshots of a home directory that barely changes cost hardly more than one of them. This is the whole reason hourly backups are practical instead of ridiculous. Scheduling # Both configs run off systemd user timers rather than cron. Cron has no idea a run was missed: if the laptop is asleep at the top of the hour, that backup just never happens and nothing tells me about it. OnCalendar=hourly RandomizedDelaySec=5m Persistent=true OnCalendar=*-*-* 00/6:00:00 RandomizedDelaySec=15m Persistent=true The rest of it is in the service files: [Service] Type=oneshot Nice=19 IOSchedulingClass=idle ExecStartPre=/bin/bash -c 'for i in $(seq 1 30); do getent hosts 192.168.1.22 && exit 0; sleep 2; done; exit 1' Persistent=true means a timer I missed while the lid was closed fires on the next boot instead of just getting skipped. Nice=19 and IOSchedulingClass=idle mean a running backup never makes the machine feel sluggish. I don't notice them. And that ExecStartPre polls for up to 60 seconds waiting for the destination host to resolve before the backup starts, so a run that fires before the network is up waits instead of failing. Retention # NAS Offsite hourly 24 6 daily 7 7 weekly 4 4 monthly 6 6 A full day of hourly snapshots locally, six hours of them offsite, then the same daily, weekly and monthly tail on both. Borgmatic runs its own integrity checks too: a repository check every two weeks and a full archive check monthly. What I don't back up # By default, I back up my whole home directory, and I have a manual exclude list. I'd rather accidentally back up too much than accidentally back up too little. I exclude build artifacts and caches (node_modules, __pycache__, .cache, .venv), toolchains that'll just reinstall themselves (.cargo, .rustup, .nvm), browser profiles that sync through their own accounts, and Downloads. I do have to be careful about my working/junk directory, though. When I was restoring some old posts from a backup, I extracted 407 GB into the root of my home folder so that I could pick out the bits of the backup that I needed. It didn't occur to me that borg would back the whole thing up. It wasn't a problem for my local NAS backup, but my BorgBase plan only gets 250 GB of storage so... oops! Note to self: Use Downloads as your scratch directory, you dummy. How I know it's working # This is the part that answers Chris's problem. His backups failed silently. Mine can't, I hope. Every borgmatic run pings an Uptime Kuma (opens in a new tab) push monitor, one per repository, on success and on failure both. Kuma is self-hosted too, running in a container on my homelab. commands: - after: action when: [create] run: - curl -fsS --retry 3 "http://<kuma-host>/api/push/<token>?status=up&msg=OK&ping=" - after: error when: [create, prune, compact, check] run: - curl -fsS --retry 3 "http://<kuma-host>/api/push/<token>?status=down&msg=FAIL&ping=" Kuma expects a ping on a schedule. If one doesn't show up, it emails me. So a failed backup alerts me, and so does a backup that never ran at all. The silence is the alarm, which is exactly the failure mode that got Chris. Restoring # A backup I've never restored from is a hypothesis, not a backup. So here are the commands. To list what's in a repository: borgmatic --config ~/.config/borgmatic/nas.yaml list To pull a single file out of the most recent archive: borgmatic --config ~/.config/borgmatic/nas.yaml extract \ --archive latest \ --path home/obsolete29/.config/borgmatic/nas.yaml \ --destination /tmp/restore-test A few things I always forget: paths inside the archive have no leading slash, --archive latest saves me looking up an archive name, and without --destination it extracts into the current directory, which is almost never where I want it. To browse instead of extract, I can mount an archive as a filesystem and copy files out normally: borgmatic --config ~/.config/borgmatic/nas.yaml mount \ --archive latest --mount-point /mnt/borg I ran that extract while writing this post and diffed the result against the live file. Identical. The passphrase # Both repositories are encrypted with the same passphrase, which borgmatic reads at runtime: encryption_passcommand: "cat /home/obsolete29/.config/borg/passphrase" This is the single point of failure in the whole thing. Lose that passphrase and both backups turn into an inert lump, no matter how many copies I have or how healthy they are. It lives in three places: the plaintext file above that borgmatic reads, my pass store, and a Recovery group in my KeePass database that syncs to my phone and my tablet. That last one is the one that counts. A passphrase that only exists on machines inside the house dies in the same fire as the hardware it was supposed to protect me from. And yes, that's a passphrase sitting in a plain text file. It's chmod 600, which protects it from other users on a running machine. While writing this post I went to double check that and discovered the laptop has no full disk encryption at all, so those permissions do exactly nothing against somebody who walks off with it. Not really a passphrase problem, to be fair to me: anyone holding that disk already has my whole home directory in the clear. But it's going on the list. This is why you write the post. Checking the boxes # Requirement How 3 copies Laptop, NAS, BorgBase 2 media types Three: internal SSD, NAS RAID 1, cloud storage 1 offsite BorgBase I'm not a backup specialist and I'm sure there are holes in this I haven't spotted yet. What does your backup strategy look like? Michael Harley Author Also on Mastodon (opens in a new tab) Bluesky (opens in a new tab)