Home  ›  Glossary  ›  Retention Policy Design

What is retention policy design?

Retention policy design is the process of deciding how long each class of backup is kept, how many daily, weekly, monthly and yearly restore points exist, and how long each is locked. The result is a set of per-class rules that balance recovery needs, legal minimums and maximums, and storage cost.

Which pressures set retention for each class?

  • Recovery: pushes retention up, since the oldest restore point that has to be reachable sets the minimum.
  • Legal and compliance floors: records such as financial, tax or health data carry minimum retention periods set by law or industry rules.
  • Legal ceilings: privacy law can require personal data to be removed once its purpose ends, which caps retention.
  • Cost: every retained restore point occupies capacity.

Because these pressures differ by data class, a policy is a small table: for each class, how long to keep, how many restore points, where they are stored and how long they are locked. Finance records, email and virtual machine images rarely share a row.

How does grandfather-father-son retention work?

Grandfather-father-son (GFS) is the most common scheme for spreading restore points over time. Daily backups (sons) are kept for a short period, weekly backups (fathers) for longer, and monthly or yearly backups (grandfathers) for the longest. The result is dense coverage of recent days and sparse coverage reaching back years, without keeping every daily copy.

As an example, a class kept as 7 daily, 4 weekly, 12 monthly and 7 yearly points holds 30 restore points that reach back seven years. Short-lived operational data might keep only the daily and weekly tiers, while records with a seven-year legal minimum need the yearly tier. Older GFS points are often moved to cheaper media, as described under backup storage tiers.

How do lock, retention and discovery time nest?

Three durations work only in one order. The time to discover an intrusion is the shortest. Retention is longer than that, so a clean restore point still exists when the intrusion is found. The lock is at least as long as retention, so no copy can be removed before its retention ends. If any of the three is shorter than the one inside it, a gap opens.

Discovery time is the hard number, because it is known only after the fact and varies widely between attacks. A thirty-day retention chosen for cost can be outlasted by an attacker who arrived forty days before discovery.

What are the common design mistakes?

  • One rule for all data: over-retains cheap data and under-retains data that is regulated or hard to recreate.
  • Retention shorter than discovery time: every restore point may already contain the attacker.
  • Lock shorter than retention: the final stretch of each copy can be deleted while the policy still lists it.
  • Enforcement only in the application: a retention setting in backup software can be changed by anyone holding a stolen credential. A storage-level lock such as S3 Object Lock in compliance mode refuses early deletion from any account.

Frequently asked questions

How long are ransomware backups kept?

No fixed period fits. The period has to exceed the time attackers can stay undetected in that environment, and a longer lock on a few key classes is often cheaper than a long lock on everything.

Can retention and compliance requirements conflict?

Yes. Some rules require records to be kept for a minimum time, while privacy law may require personal data to be removed. Per-class policies exist to handle both.

What does GFS stand for?

Grandfather-father-son: a retention scheme that keeps daily, weekly and monthly or yearly restore points for progressively longer periods.

What happens to expired restore points?

Once retention and lock both end, the software or storage can delete them. Until the lock ends, deletion requests are refused.