Data loss happens more often than we hope, and most people are unprepared when it strikes. The author recalls a childhood incident where family photos stored on a single external drive were lost after the drive was reformatted for a TV set‑top box. Although the photos were eventually recovered, the episode taught that important files should never be kept in only one place. Numerous threats can corrupt or erase data: hardware failure, theft, bit rot in cold storage, or gradual leakage in SSDs that degrades stored bits over time. Consequently, the first principle of data safety is to maintain a backup—a copy of files stored elsewhere. However, a mere mirror of the original drive is insufficient because it does not allow recovery from user error or ransomware; restoring to a previous state requires the ability to go back in time. Mirroring technologies such as RAID 1 therefore do not meet this need, and a snapshot‑based approach is recommended instead. The frequency of snapshots is guided by a Recovery Point Objective (RPO). For critical financial systems the RPO can be under thirty seconds, while small enterprises may tolerate twenty‑four hours or more. With a 24‑hour RPO, keeping every snapshot would generate roughly seven per week, thirty per month, and 365 per year if none are pruned, creating a substantial storage burden. To manage this, backups must be rotated. A simple strategy retains a fixed number of recent snapshots—say fourteen days—deleting the oldest when a new one is added. Yet optimal policies vary the granularity: recent data deserves frequent snapshots, while older data can be stored less often. An example is a GFS‑rotated scheme where daily snapshots are kept for two weeks, weekly snapshots for seven weeks, and monthly snapshots for a year. Storing identical copies of unchanged files wastes space, so deduplication is employed. By using hard links, a single instance of a file is stored and referenced by each snapshot; this technique is used by tools like rsnapshot and constitutes an incremental backup, saving both storage and network bandwidth—an important consideration when the backup target is a cloud service where transfer costs apply. Implementing such a system can involve rsync to pull files and cronjobs to schedule the backup scripts, allowing the process to run on many machines while preserving file metadata such as permissions and ownership. Complications arise when backing up modern environments. Docker containers often create files owned by root, and a cronjob running under a non‑privileged user may lack permission to read them, causing backup failures. Additionally, many web‑apps rely on databases that flush changes to disk in batches, risking inconsistency if a backup captures an incomplete state. The solution is to have the backup process dump the databases and run with sufficient filesystem privileges on Docker volumes. Finally, to guard against hardware‑specific failures, the author advises keeping backups on two different media types and maintaining an offsite copy—either in the cloud or on a separate machine such as a Mac—to ensure that a single point of physical damage does not destroy all copies. Together, these layers—snapshot frequency, rotation, deduplication, proper permissions, database dumps, and geographic diversity—form a comprehensive strategy that acknowledges that backups are far from simple.
