How to Automate Backup Rotation and Retention

Keeping every backup ever taken forever isn't practical — disk space is finite, and most old backups have little ongoing value. This guide covers implementing a sensible, automated retention policy.

Why Retention Policy Matters

  • Unlimited retention eventually fills any disk, regardless of size
  • Most incidents are discovered within days, not months — very old backups rarely get used
  • A structured policy balances recovery flexibility against storage cost

A Common Retention Pattern: Grandfather-Father-Son (GFS)

TierFrequencyRetention
Son (daily)Every day7 days
Father (weekly)Every Sunday4 weeks
Grandfather (monthly)First of the month6–12 months

This gives fine-grained recent recovery options while keeping longer-term history at a manageable storage cost.

Simple Retention with find (Time-Based Only)

find /var/backups -type f -mtime +7 -delete

Simple, but doesn't implement tiered retention — just deletes everything older than N days uniformly.

Implementing GFS Retention with a Script

sudo nano /usr/local/bin/backup-with-rotation.sh
#!/bin/bash
BACKUP_DIR="/var/backups"
DAY_OF_WEEK=$(date +%u)
DAY_OF_MONTH=$(date +%d)
TIMESTAMP=$(date +%F)

# Always take the daily backup
mysqldump -u root --all-databases | gzip > "$BACKUP_DIR/daily/backup-$TIMESTAMP.sql.gz"

# Copy to weekly on Sundays
if [ "$DAY_OF_WEEK" -eq 7 ]; then
    cp "$BACKUP_DIR/daily/backup-$TIMESTAMP.sql.gz" "$BACKUP_DIR/weekly/"
fi

# Copy to monthly on the 1st
if [ "$DAY_OF_MONTH" -eq 01 ]; then
    cp "$BACKUP_DIR/daily/backup-$TIMESTAMP.sql.gz" "$BACKUP_DIR/monthly/"
fi

# Retention cleanup
find "$BACKUP_DIR/daily" -type f -mtime +7 -delete
find "$BACKUP_DIR/weekly" -type f -mtime +28 -delete
find "$BACKUP_DIR/monthly" -type f -mtime +365 -delete

Retention for Object Storage (S3-Compatible)

Rather than a script, use your provider's native lifecycle policy feature — configure rules directly in the bucket settings to automatically transition or delete objects based on age, avoiding the need for scripted cleanup on the remote end entirely.

Monitoring Backup Storage Usage

du -sh /var/backups/*

Track this over time to confirm your retention policy is actually keeping storage growth bounded as expected.

Choosing Retention Periods for Your Situation

ConsiderationImpact on Retention
Compliance requirementsMay mandate specific minimum retention periods
Storage costLonger retention costs more; balance against actual recovery value
How quickly issues are typically discoveredShorter discovery windows can justify shorter retention

Common Mistakes

  • No retention policy at all, letting backups accumulate until disk is full
  • Retention so aggressive that a needed older backup is already deleted when you discover you need it
  • Cleanup script silently failing, with no monitoring to catch it

Verifying Retention Is Actually Working

ls -la /var/backups/daily/ | wc -l

Periodically confirm the count of retained backups roughly matches your intended policy — catching a broken cleanup script before it fills the disk.

Related Articles

  • Backup Strategy 101: The 3-2-1 Rule Explained
  • How to Back Up to Object Storage (S3-Compatible)
  • How to Check and Manage Disk Usage on a Linux VPS
  • backup retention, backup rotation, grandfather father son, backup policy
  • 0 Kasutajad peavad seda kasulikuks
Kas see vastus oli kasulik?

Seotud artiklid

Backup Strategy 101: The 3-2-1 Rule Explained

Before diving into specific backup tools, it's worth understanding the industry-standard...

How to Back Up to Object Storage (S3-Compatible)

S3-compatible object storage provides durable, cost-effective off-site backup storage —...

How to Test and Verify Your Backups Actually Work

A backup that has never been restored is not a verified backup — it's an assumption. This...

How to Create a Disaster Recovery Plan for Your VPS

A disaster recovery (DR) plan is a documented, tested procedure for restoring service after a...

How to Use VPS Provider Snapshots Effectively

Most VPS providers offer a snapshot feature — a point-in-time image of your entire server....