Backup Retention Policies and Safe Pruning Strategies

Retention is the policy that says which backups survive and which get a dignified deletion. Without one, "keep everything" quietly becomes "pay for everything and trust nothing": storage costs creep, restores slow down because there are fifty copies of the same schema, and old archives can outlive the very vulnerabilities the newer ones were built against. A tiered retention policy tuned to your RPO and compliance obligations is what separates a backup system from a landfill.

Why unbounded retention is a liability

Storage is the obvious cost and the smallest. Every extra copy is another restore target you must exclude during an incident, and another surface that signs your leak if the bucket goes out the door. Compliance frameworks usually say what to keep and for how long; security frameworks say the opposite. The policy you write reconciles both before a deadline forces the choice.

Grandfather-father-son: the durable default

• Hourly copies: keep the last 24, so any single day can be inspected at hour precision.
• Daily copies: keep the last 30, covering a 24-hour RPO with margin.
• Weekly copies: keep the last 8, roughly two months of rollback options.
• Monthly copies: keep the last 12, for yearly audit and forensics.

This costs a fraction of keeping everything forever, and it hands most applications every restore target they will ever need.

Encoding the policy in restic

Restic expresses the tiers directly in the forget command, and the flag names map one-to-one onto the list above:

restic -r sftp:offsite:/backups/app forget   --keep-hourly 24 --keep-daily 30   --keep-weekly 8 --keep-monthly 12 --prune
restic -r sftp:offsite:/backups/app snapshots

forget marks snapshots for removal and --prune reclaims the chunk storage in the same run. restic never deletes a snapshot that a later policy still requires, so the hierarchy stays coherent even when the schedule drifts.

Encoding the policy in age-based files

Plain archives named with a date stamp get the same shape with find -mtime, coarse but effective for gzip files:

# daily archives: last 30 days only
find /var/backups -name '*.sql.gz' -type f -mtime +30 -delete
# weekly archive tier: keep 8 weeks
find /var/backups/weekly -name '*.tar.gz' -type f -mtime +56 -delete

Keep the tiers in separate directories (daily/ and weekly/) so the two find commands never fight over the same files.

Verify after you prune

Retention policies prune in seconds and destroy in seconds. The correct order is always: create the snapshot, apply retention, prune, then verify that what remains still restores.

restic snapshots | tail -20
restic check -r sftp:offsite:/backups/app
restic restore latest -r sftp:offsite:/backups/app   --include /srv/app/data --target /tmp/retention-verify --dry-run

A --dry-run restore proves the tree is navigable without writing data anywhere.

Review the policy annually

Retention should follow business changes, not the other way around. Put a calendar reminder to reread the tier list on the same day you rotate certificates, and keep the policy in the runbook as a file, not a conversation: the person restoring at 2 a.m. reads the file.

Takeaway

Retention is a written, tiered, encoded, verified policy — not a hope. The grandfather-father-son pattern keeps one day at hour precision and one year at month precision for a fraction of the landfill cost, and every pruning run ends with a restore-verified snapshot list. Netbay provisions the VPS that hosts these archives in under a minute at netbayhosts.in, so the policy you write today has a home by tonight.