Rotation and Retention Policies
Retention is what turns "I have backups" into "I can recover from last week". The goal is to keep enough history for rollback while preventing backups from filling disks or costing too much offsite.
- Pick a retention schedule (daily/weekly/monthly).
- Implement pruning locally and remotely.
- Always test pruning rules with
-printbefore-delete. - Keep at least one offsite copy for longer retention.
Common retention schedules
Start with a simple schedule and adjust:
- Daily: 14 days
- Weekly: 8 weeks
- Monthly: 12 months
If you have strict RPO requirements, increase daily retention or add more frequent database dumps.
Prune local backups (safe workflow)
First list what would be deleted:
BACKUP_DIR="/backups"
find "$BACKUP_DIR" -type f -name 'wp-*.tar.*' -mtime +30 -print
find "$BACKUP_DIR" -type f -name 'wp-*.sql.*' -mtime +30 -print
Then delete:
find ... -delete permanently removes files. Always run the list-only version first.
BACKUP_DIR="/backups"
find "$BACKUP_DIR" -type f -name 'wp-*.tar.*' -mtime +30 -delete
find "$BACKUP_DIR" -type f -name 'wp-*.sql.*' -mtime +30 -delete
Prune remote backups
If you use rclone, you can delete files older than a threshold.
List candidates:
rclone lsf remote:wp-backups/site-a --recursive | sed -n '1,60p'
Delete old files (example: older than 90 days):
Remote deletion is irreversible. Confirm the target path and run on a narrow scope.
rclone delete remote:wp-backups/site-a --min-age 90d
Keep a "latest" pointer
If you store timestamped files, a latest symlink (local) or latest.txt (remote) can help automation.
ls -1 /backups | sort | tail -n 20
Next steps
- Logging and verification:
opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/backup-logging-and-verification.mdx. - Offsite redundancy:
opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/offsite--local-redundancy.mdx.