Backups fail for ordinary reasons: a file gets overwritten, a laptop goes missing, or ransomware encrypts shared folders before anyone notices. CompTIA A+ Core 2 (220-1202), Domain 4.0 Operational Procedures, Objective 4.3 Backup rotation schemes. A backup rotation scheme is a planned schedule for keeping and reusing backup copies over time. In this guide, you'll learn what rotation does (and what it doesn't), how to think about onsite vs. offsite copies, how Grandfather-Father-Son (GFS) works in practice, and how the 3-2-1 backup rule checks whether your plan can survive real incidents. These are exam topics, but they're also daily tasks in help desk and junior admin roles.
What a backup rotation scheme really does (and what it doesn't)
A rotation scheme solves a simple problem: one backup is rarely enough. If you only keep "the latest," you lose the past. That becomes painful when the most recent backup contains the same mistake as production, such as corrupted data, encrypted files, or an accidental mass delete.
Rotation keeps multiple restore points across time. As a result, you can roll back to last night, last week, or last month, depending on what happened and when you noticed it. Rotation also reduces the risk of "bad backups" because it spreads your chances across many runs. If Tuesday's job fails, Monday's copy still exists. If last week's set is damaged, last month's set might still be usable.
At the same time, rotation limits storage growth. Most organizations can't store forever, at least not on fast storage. Rotation gives a controlled way to reuse media (tapes, drives, or snapshot slots) without losing the ability to recover older versions.
However, rotation is not magic. It won't fix a backup that never ran, never included the right data, or can't be restored due to permissions. It also won't correct poor documentation. If no one knows which set to restore, the history you saved becomes hard to use.
Rotation is about time and history. Reliability still depends on monitoring and restore testing.
The plain-language goals: restore time, restore point, and keeping history
Two terms appear often in both operations and exam prep: RTO and RPO.
RTO (Recovery Time Objective) means how fast you need systems or files back after an outage. If payroll must run by 9 a.m., your RTO for that payroll data is short.
RPO (Recovery Point Objective) means how much data loss you can accept, measured by time. If your last good backup is from midnight, then your RPO is "up to one day" of lost changes.
A quick example makes the difference clear. Restoring a single payroll spreadsheet from yesterday aims for a small RTO and a small RPO. By contrast, restoring a server after ransomware might accept a longer RTO (hours), but still needs an RPO that prevents losing days of work.
"Keeping history" connects to how deep your rotation goes. Daily copies help with recent mistakes. Weekly copies cover problems noticed late. Monthly copies help with audits, long-running errors, and slow-burn corruption.
Common failure points you prevent with rotation
Rotation reduces several common backup failures seen in real environments:
- Overwritten backups: A single rolling backup can replace last week's good copy with today's broken one.
- Silent job failures: If one run fails, you still have earlier points in the schedule.
- Corruption copied forward: When corruption enters data, later backups may preserve the damage, so older sets matter.
- Late discovery of deletes: A user may notice a missing folder after days, not hours.
- Malware encryption: Ransomware often encrypts mapped drives and reachable backup locations, so older, separated copies help.
Still, rotation works best when you pair it with alerts and regular test restores. Without those, you may only learn your backups are unusable during an emergency.
Onsite vs. offsite backups: choosing where copies live
Rotation answers "when," but you also need "where." Onsite and offsite backups each trade speed, cost, and risk. The right mix depends on what you protect, how fast you must restore, and what threats you face.
Onsite backups stay in the same physical location as the systems. Common examples include an external drive stored in a locked cabinet, a local NAS in the server room, or a backup server in the same office. Onsite copies restore quickly because they sit close to the data and don't depend on the internet.
Offsite backups live somewhere else. That "somewhere" could be cloud storage, a second office, a colocation rack, or even a safe deposit box for removable media. Offsite restores can be slower, yet they protect against events that wipe out the building or everything connected inside it.
Separation matters because many incidents are location-based. Fire, flooding, and theft can remove both the device and its local backups in minutes. Ransomware can also spread to anything online and trusted, including backup shares. Offsite copies reduce the chance that one event destroys every copy.
A practical approach often uses both. Keep onsite copies for fast, routine restores, and keep offsite copies for worst-case scenarios.