Backup retention and rotation

The policy is a decision, not a default

Automated backups convert a "do we still have last Tuesday?" question into a knob you turn. The two numbers that define it are the retention window (how far back you can restore) and the interval (how much work you could lose). The default hosting marketing speaks in daily and weekly, but the policy should be yours: what does the business tolerate losing, measured in minutes of work, and how far back does a restore need to go?

A practical floor for a small commerce site:

For a business site that changes a page a week, daily-plus-monthly is usually enough. For a product or commerce site with orders, the ceiling is the transaction history, and the retention must reach the business's own week- and day-precision.

Rotation, so the store does not creep

The correct rotation keeps the newest, every-other, and the oldest-named versions. Three models:

• GFS (Grandfather-Father-Son): daily kept 7 days, weekly kept 4 weeks, monthly kept 12 months. This is the classic; it gives you the daily and monthly needles without an unbounded store.
• Time-based: keep everything for 7 days, then one per week for the following 8, then one per month for a year. This is the "keep last N" model, and it self-heals older gaps.
• Count-based: keep the most recent 20 backups, rotate the oldest out. Cheap, but it has the failure mode of surviving a bad day: if the site breaks and a nightly job re-runs for a week, a count-based store can rotate out the good backup before anyone notices.

For a non-critical static site, GFS is overkill's worth of storage; the count model plus one tagged monthly works. For anything with a database, the restore drill is the real proof, and the storage math needs two rules: keep the newest, keep a pointer to the monthly, and delete nothing that the drill has not demonstrated restores.

Storage math to keep the bill sane

A retention is only useful if the storage cost stays under control. The arithmetic: a 2 GB site, 1 daily x 14 + 1 weekly x 4 + 1 monthly x 12 = 14 + 4 + 12 = 30 generations. At 2 GB each, that is 60 GB, which most plans treat as cheap until you multiply by the number of sites.

Two levers keep the store flat:

• Offsite, so the storage sits in a cheaper tier (object store, remote attached backup) and one host failure does not take the backups with it. The hosting migration context usually keeps backups off-host.
• Compressed, DB-aware snapshots rather than full dumps; a site that dumps a 5 GB database every night compounds fast.

Prove the retention works

A retention policy is a promise, and the restore drill is the audit. Run it quarterly: take the oldest generation in the schedule (the 12-month-old monthly), restore it into a staging directory, and confirm the site loads and the database restores. If the oldest restore fails, the retention is pointless regardless of its size, so the drill is part of the policy.

• Set the retention in the automated job, not mentally: the tool (cron + script, a control-panel scheduler, a WordPress backup plugin) should prune by the policy and no human should rotate manually.
• Keep the hosting SLA clear: the SLA is what you rely on within the window; your automated retention is the layer that survives alone.

The shape to write down

A one-line policy is the deliverable: "The site is backed up nightly, kept 14 days, weekly, kept 8 weeks, monthly, kept 12 months, offsite, and every monthly is restore-tested." That sentence now drives the scheduler, the storage budget, and the drill. The backup before changes article covers the ad-hoc backup that ships a deploy; this one is the long-term conservation layer on top.