Backups Aren't Simple

A practical, cautionary take on why backups are deceptively complex: it starts with a personal data-loss anecdote and builds into concrete principles and pitfalls. Backups must be copies, not mirrors - RAID isn't a substitute - because ransomware, accidental deletes, or destructive scripts require point-in-time recovery. Decide an RPO (how much data loss you can tolerate), take snapshots, and rotate them with a sensible granularity (frequent recent snapshots, sparser older ones), i.e., a GFS-style rotation. Because file changes are fat-tailed, deduplication and incremental snapshots (hard links or chunk-level dedupe) massively reduce storage and bandwidth; rsync/rsnapshot illustrate the idea versus differential/full approaches.

Operational realities multiply the complexity: Docker-created root-owned files and databases that flush asynchronously break naive filesystem copies, so dump DBs and handle permissions carefully. Hardware-model failures argue for multiple media and offsite copies (3-2-1). Cloud object stores add problems: metadata loss and high costs for many small files, pushing you toward tar/chunk strategies that are hard to get right. The practical recommendation is to use mature tools (Borg, Restic) that provide encryption, chunk dedupe, and checksums, and to verify restores regularly (roughly semiannually). Also, avoid scheduling backups at odd hours that could mask failures.