Backups Aren't Simple
TL;DR
Rolling your own backups looks like an afternoon's work, until each fix exposes another problem. Snapshots, rotation, deduplication, root-owned Docker files, live databases, offsite copies and S3's per-object pricing pile up. So Aleksandar Filipovski concludes you should use Borg or restic and test restores.
The article
- A second copy is the start. But a mirror like RAID 1 also copies ransomware, bad scripts and accidental deletes. So backups need snapshots you can go back to.
- Daily snapshots pile up fast. So Filipovski keeps daily, weekly and monthly sets on separate rotations, known as GFS. Snapshots stay dense near today and grow sparser further back.
- Most files never change between snapshots. rsnapshot-style hard links store each unchanged file once and still survive rotation. That also cuts bandwidth to a cloud target.
- Real services break the rsync-and-cron setup. Docker containers write root-owned files that a user cronjob can't read. Databases buffer writes in memory, so a file copy can restore as corrupt unless you dump them first.
- The 3-2-1 rule means 3 copies, on 2 media types, with 1 offsite. It leads to S3, which drops file metadata and charges heavily for many small objects. That pushes you into chunked tarballs that are hard to get right.
- At that point Filipovski gives up and recommends Borg or restic, which handle encryption, chunk-level dedup and checksums. Filipovski also advises a restore test every six months. The addendum warns against cron jobs in the 2-3 AM daylight-saving hour.
Why it matters
Anyone running a homelab or a small self-hosted service who still backs up with a script will see where that script breaks. The original walks through each step at a relaxed pace. It ends with an addendum on ZFS and a reader's notes on consistency groups, ACLs and sparse files.
The discussion
A friendly, story-heavy thread where people traded data-loss anecdotes and favorite tools, naming restic and ZFS snapshots most often. The real arguments were about what counts as a backup, such as sync and replication versus point-in-time copies. Another was whether cloud storage you rent can be trusted as one of your copies.
You're buying restores, not backups
The most repeated point was that a backup nobody has restored from proves nothing. A former Veritas engineer's line about being in the restoration business set the tone. One shop restores customers' systems once a year on its own hardware, and a SaaS runs an automated weekly restore into a fresh cluster. Some found the article's six-month restore interval too lax, and one commenter warned that Glacier makes restore drills hard.
We are not in the backup business. We are in the restoration business.
We now automatically run a scheduled restore with verifications on a weekly basis. This requirement does shape your environment, so keep that in mind!
Sync and redundancy are not backups
Whenever someone offered Syncthing or geo-replicated storage as their backup, replies pointed out that a delete or malware run reaches every copy within seconds. Commenters separated redundancy, which keeps a service up, from backups, which roll you back, and from archives, which hold data for decades. The fixes they named were versioning, append-only stores, and provider-enforced object lock, so a stolen API key can add data but not destroy it. A SaaS operator warned that a forced delete, or deleting the whole project, can still bypass some providers' retention locks.
If you accidentally delete something, how long does it take for the delete to propagate to all of your geographically separated datacenters? You need some sort of point-in-time snapshots to be able to recover from accidents and silent corruption.
You want to make sure the append only is enforced by the hosting provider rather than duplicity. Your backups should be resistant to having an attacker on the system who can run arbitrary commands with duplicity.
What people actually run
restic came up most, often with the Backrest GUI, though one user noted Backrest stores the repository password in plaintext on Windows. Compared with Kopia, restic was easier to script and pipe database dumps into, while Kopia's server suited laptops backing up to a home box. A ZFS camp argued that sanoid/syncoid snapshots with pull-mode offsite replication cover most needs. Others kept it minimal with rsnapshot, plain rsync to a NAS ("it is just files"), or GNU tar's incremental index feeding write-only Glacier.
If you have a good system for organizing ZFS datasets, and separating ephemeral from persistent data (e.g. [2]), then this is 90% of the backup requirements already fullfilled.
I am thinking of switching to Restic as it seems like it is more suitable for people who want a tool at the complexity level of tar/git CLI with declarative config, rather than something imperatively configured.
Consistency, databases and privileges
The sharpest technical addition, which Filipovski later folded into the article, was that snapshotting a database apart from its app can capture mismatched states. Others suggested filesystem or LVM snapshots to avoid database downtime, and sqlite3-rsync for SQLite. One commenter flagged the privilege-escalation risk in giving the backup job access to Docker volumes, and runs only restic under a locked-down root systemd timer. Filipovski answered that rootless Podman is the ideal, but most software can't run that way, and accepts the risk for now.
If you have multiple programs accessing the storage, s.a. a database (that you are snapshotting) and the application using the database, then you are risking an inconsistent snapshot when the database state you wrote is ahead or behind the application state.
What I do is having a minimal systemd timer under root that only calls restic for backing up files (with some additional systemd seucurity restrictions). App-dependent backup logics, like dumping databases, are done by user/container-level cronjobs separately.
Can you trust the cloud with your copy?
Many data-loss stories involved a provider, like OneDrive cutting its "lifetime" storage or a Chinese provider throttling exports. A PBS station risked losing 50TB when its storage vendor went quiet, and getting full-quality originals out of iCloud Photos proved hard. One side said online backup should never be your primary method. The other said a cloud copy is fine if you control the primary, since the provider vanishing just as your disk dies is unlikely.
online backup should not be your primary method of backup, you're one billing, identity theft, financial issue, or health issue away from getting your backup nuked
The probability of a hard drive failure or ransomware at the same time as backblaze or aws going out of business is pretty much not worth thinking about.
Consensus
Use a proven tool like restic, Borg or ZFS snapshots instead of a homemade script. Keep point-in-time history rather than a mirror, keep one copy offsite or unplugged, and test restores, because an untested backup is a guess.
Dissent
A few said the article overcomplicates it. A household needs a synced copy elsewhere plus a history mechanism, or simply ZFS/btrfs snapshots replicated onsite and offsite. It does not need an "encrypted, chunk-level" enterprise setup.