Backup Rotation

In June 2014, Code Spaces ran a successful code hosting business on AWS. An attacker gained access to their AWS console and began deleting EC2 instances. While the team scrambled to regain control, the attacker also deleted all EBS snapshots and S3 backups. Within 12 hours the company was gone. Not because they lacked backups, but because every backup copy lived on the same control plane as production.

Backup rotation is the discipline of managing which copies you keep, how long you keep them, and where they live. Without rotation, you either store every backup forever (and go bankrupt on storage costs) or you overwrite the same slot repeatedly (and lose the ability to recover from corruption that started weeks ago).

The core question rotation answers: when the disaster arrives, how far back can you reach for a clean copy?

Rotation is a lifecycle policy for backup copies. Every scheme answers the same three questions: how many copies exist at any moment, how much time coverage do they provide, and how much storage do they consume.

The most common rotation scheme is Grandfather-Father-Son (GFS), invented for tape libraries in the 1980s and still the default policy in Veeam, Rubrik, AWS Backup, and Azure Backup. Other schemes exist (Tower of Hanoi, round-robin, FIFO) but GFS dominates production use because it provides the best coverage-to-storage ratio.

A rotation scheme is not a backup strategy by itself. It sits on top of a backup type (full, incremental, differential) and determines how long each copy survives. Without rotation, you have a pile of backup files. With rotation, you have a structured recovery timeline.