Why 'Just Back It Up' Spirals Into Deduplicated, GFS-Rotated Snapshots

A single copy of your data is never enough, and the reasons compound fast. Drives die, get stolen, or silently rot as magnetic domains drift and NAND cells leak charge. But a naive mirror doesn’t help either: ransomware, a fat-fingered delete, or a script that zeroes everything will faithfully propagate to the mirror too. That rules out RAID 1 as a backup and forces point-in-time snapshots, which introduces the first real design decision — your Recovery Point Objective, the amount of data you can afford to lose, ranging from sub-30-second targets at financial institutions to a day or more for small shops.

Each constraint layered on top spawns another mechanism. Keeping every snapshot is unaffordable, so you rotate them — and because recent history matters more than old history, uniform rotation gives way to a Grandfather-Father-Son scheme (daily, weekly, monthly tiers). Since most files never change between snapshots (file churn follows a fat-tailed distribution, much like how video codecs exploit near-identical frames), you deduplicate with hard links so one on-disk copy is referenced by many snapshots, which also slashes network transfer costs when the second copy lives in the cloud. Tools like rsnapshot, rsync, and cron stitch this into an incremental, deduplicated, GFS-rotated, snapshot-based system that preserves file metadata and scales to more machines cheaply.

Then production reality breaks it again. Docker containers write root-owned files that a user-level cron job can’t read, so backups silently fail. Databases buffer writes in memory and flush in batches, meaning a naive filesystem copy can capture a corrupt, unrestorable state unless you dump the database explicitly. Guarding against a bad batch of drives argues for spreading copies across different media, and physical-disaster resilience pushes you toward an offsite or cloud copy. The takeaway: ‘have a backup’ is a deceptively simple instruction that unpacks into a stack of hard-won engineering constraints, each one added because a specific, ordinary failure taught someone it was necessary.