Backup Retention: How Far Back Your Restore Must Reach

The redirect had been live for six weeks. It fired only for visitors arriving from search results, which is why the owner never saw it, and it had been installed through a vulnerability in a plugin that had since been updated. By the time a customer mentioned it, every daily backup in the account was taken while the redirect was active. The site had thirty restore points and not one clean copy. The backup system had worked perfectly. The retention window was the failure.

Retention is the part of backup design that gets the least attention because it does not show up in an interface until it is too late. Frequency is easy to sell: hourly, real-time, continuous. Retention is the quieter setting, often a number of days chosen by a default, and it decides whether recovery is possible at all. A backup you cannot reach back past the incident is a rollback mechanism for bad updates, not a recovery plan for a compromise.

The question to answer is not "how often" but "how far back". The answer comes from two numbers: how long a problem can stay invisible, and how long it takes to notice once it starts causing damage. The window has to be longer than both.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. The price does not change, and the arithmetic below applies to every provider, including the ones named at the end.

Detection lag decides how far back you need to reach

Most compromises are not discovered on the day they happen. A injected script that only fires for search traffic, a new administrator account created at three in the morning, a scheduled task that rebuilds a payload after cleanup: these survive because nobody is looking at the right screen. The gap between the first malicious change and the discovery is the detection lag, and it is usually measured in weeks.

That gap sets the floor for retention. If a site is typically discovered to be compromised thirty days after the first change, a fourteen-day window cannot contain a clean copy. The operator ends up cleaning a live site by hand, which works until the same entry point is used again, and the backup set is revealed as a set of infected snapshots.

There is a second lag that matters more on stores: the lag between the change and the first customer complaint. A checkout that silently drops orders, a price that changes only for a segment of visitors, a coupon that no longer applies. By the time the complaint arrives, the cause may be a database change from three weeks earlier, and the fix is a restore to before it. The same window applies.

Frequency and retention solve different problems

Frequency sets the recovery point objective, the maximum amount of work that can be lost. Retention sets the recovery time objective for a compromise, because it determines whether a clean point exists to restore from. They are independent settings, and almost every comparison page treats them as one number.

The useful configuration is a ladder rather than a single number. Hourly or twice-daily copies kept for a week handle the operator error and the bad update, where the loss is measured in hours. Daily copies kept for a month handle the delayed complaint. Weekly or monthly copies kept for a year handle the compromise that was live for a season and the legal or accounting request that arrives long after everyone stopped thinking about it.

That ladder is what rotation schemes have done for decades under the name grandfather-father-son. Seven daily, four weekly, twelve monthly, and a few yearly copies. The names are old because the problem is old. The implementation moved from tapes to object storage, and the arithmetic did not change.

A rotation scheme that survives a bad month

The rule to protect is simple: never let the newest copy overwrite the only copy from before the incident. Daily snapshots on a fixed seven-day cycle violate it by design, because day eight deletes day one. A ladder violates it less often, but it still needs a destination that keeps old versions when the writer asks to delete them.

Versioning on the bucket is the control that makes the rotation safe. The backup job can prune its own retention policy, and the bucket still holds the older object versions for whatever period the lifecycle rule sets. Object lock goes further: a version can be made immutable for a fixed term, so neither a compromised site nor a tired operator with the wrong command can remove it.

# Keep a ladder locally, then rely on bucket versioning for the deep history.
restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --keep-yearly 3 \
  --prune

aws s3api list-object-versions \
  --bucket site-backups \
  --prefix db/ \
  --query 'Versions[?LastModified>=`2026-07-01`].[Key,VersionId,LastModified]'

The first command is the routine. The second is the check you run during an incident, when you need to know whether an object from before a date still exists. Having the command written down is worth more than remembering it under pressure.

One trap is worth naming: an incremental backup chain that depends on every link. If the chain is stored on the same compromised host and the attacker deletes one middle increment, the later copies are unreadable. Full copies on a monthly cadence are wasteful and much easier to reason about. A mix works: weekly full, daily incremental, and at least one full copy older than the detection window.

Pruning is where the cost lives

Storage is cheaper than it has ever been, and retention still has a cost. The first full copy dominates. After that, the incremental change on a typical WordPress site is small: new uploads, new posts, new orders, plus a database dump that is mostly the same rows. A site with a large media library and a busy store changes more, which is exactly where retention matters most and costs most.

Run the arithmetic for the site in front of you rather than repeating a rule of thumb. A 20 GB site with 20 percent monthly churn, keeping twelve monthlies plus weekly and daily copies, needs a destination sized for the first copy plus the retained change, not for twelve full copies. The number is usually smaller than people fear, and the exercise makes the trade-off visible.

There is a case for keeping media separately. Uploads rarely need the same granularity as the database, and they are the bulk of the storage. A monthly full archive of wp-content/uploads plus a daily database dump gives most of the recovery value at a fraction of the cost. The exception is a site where the media is the product, such as a photographer's portfolio or a document archive, where the uploads deserve the same ladder as the database.

Deleted data is the other cost. Retention policies that keep everything forever conflict with deletion requests, with data minimisation rules and with the ordinary expectation that a customer who asks to be forgotten is actually forgotten. The backup set is part of that discussion. A reasonable position is a defined window for each class of data, a documented process for deletion requests that includes the backups, and a legal hold that suspends pruning when litigation or an investigation is declared.

Retention has legal and privacy edges

A backup is a copy of personal data, and the rules that apply to the live site apply to the copy. If the site collects names, addresses and order history, then so does the bucket. The practical consequences are modest but real: encrypt the destination, restrict who can read it, log access, and know which jurisdictions the storage region belongs to.

Deletion requests are the awkward part. Restoring an old backup can bring back records that were deleted on request, which is a compliance problem created by a recovery action. The usual answer is a documented exception for backups held for a defined period, followed by a process that reapplies the deletion after a restore. Write that process down before the first restore, not after a request arrives.

Legal hold is the opposite case. When a dispute or an investigation is likely, the retention policy must stop deleting. Object lock, a legal hold flag or a manual freeze on the bucket all work. The important property is that the person who knows about the dispute can suspend deletion without needing the person who owns the backup script.

The oldest copy in the window should be restored on a schedule

Retention is only real if the oldest copy still restores. Storage providers degrade, lifecycle rules misfire, encryption keys get rotated and old objects become unreadable. The only way to know is to restore the oldest copy in the window once a year, into a scratch environment, and check that it comes up. That is a different drill from the monthly restore of the newest copy, and it catches the class of failure that only appears at depth.

The exercise also answers the question that matters during an incident: what is the actual recovery point? Not the retention setting, but the age of the last copy known to restore into a working site. Those two numbers are often different, and only one of them is useful at two in the morning.

The free version of this plan is a bucket with versioning, a weekly full archive and a daily database dump, plus a calendar entry for the annual oldest-copy test. Paid services sell the ladder as a feature. Jetpack's backup service keeps restore points off the site's disk with a history that extends beyond the default week, and SiteGround's panel snapshots cover the recent rollback on a schedule most owners never configure themselves.

Buy the longer window when the site takes money, holds customer records or has a history of undetected problems. Do not buy it for a brochure site whose content changes twice a year and whose host keeps a ninety-day snapshot; there, a quarterly export to a second cloud drive is a better use of the money. The decision rule is a sentence: the retention window must reach back further than the longest time a problem has ever stayed hidden on this site. If nobody can name that number, ninety days is a defensible default, and a yearly test of the oldest copy is the proof.