Everyone asks how often to back up. Almost nobody asks how long to keep the backups, which is strange, because retention is what decides whether you can recover from the slow problems. And the slow problems are the ones that hurt.
A site that goes down hard gets noticed in minutes. A site that has been quietly corrupting data, or serving spam links to Google, or running an infected file since some update three weeks ago, gets noticed whenever someone happens to look. If your backups only go back a week, every copy you own is already broken.
Retention is protection against late discovery
Split site problems into two types.
Fast failures announce themselves. White screen, 500 error, checkout broken. You know within the hour and yesterday's backup fixes it. Short retention is fine.
Slow failures hide. Malware injected into a theme file that only shows itself to search engines. A plugin conflict mangling a database table you rarely touch. A redirect added by someone with stolen credentials. An SEO plugin that started noindexing pages after an update. These sit there for weeks.
For slow failures, retention is the entire game. The question is not whether you have a backup, it is whether you have one from before the damage started. Seven days of retention means you can recover from anything you spot within a week and nothing else.
The fix: check your retention setting right now, then ask honestly how long a subtle problem could go unnoticed on your site. If nobody looks at analytics for a fortnight, seven days of backups is not enough.
What is a sensible window
Thirty days is the practical sweet spot for most small business WordPress sites. It is long enough to cover a problem you noticed late, an update that caused trouble you only connected weeks later, or a staff member who deleted something and did not mention it.
Longer than 30 days has diminishing returns for most sites. A four month old backup of an active site is so out of date that restoring it creates a bigger mess than the original problem. You would cherry-pick from it, not restore it wholesale.
There are exceptions worth knowing about:
- Legal or financial records. If your site holds invoices, contracts or transaction records, your record keeping obligations may run for years. Backups are the wrong tool for that. Export the records properly.
- Seasonal businesses. If your site changes once a year, keep an annual snapshot outside the normal rotation.
- Before major changes. Keep a labelled copy from before a redesign or a big migration, separate from the rotating schedule, for as long as you might want to reference the old version.
Keep fewer copies, further apart
Here is a trick most people miss. Retention does not have to mean keeping every backup for the whole window. Thirty daily backups is a lot of storage for very little extra safety, because backups from consecutive days are nearly identical.
A tiered approach gives you the same protection for a fraction of the space:
- Keep all recent backups for the last few weeks. These cover fast failures.
- Keep one per week going a bit further back. These cover the slow ones.
- Keep one per month for anything longer, if you need it at all.
The result is a longer reach for less storage. Most decent backup tools support this. It is often called grandfather-father-son, which is a horrible name for a genuinely sensible idea.
Retention has a cost, and it is not just storage
Two honest downsides worth naming.
First, storage costs money once sites get large. A 20GB site kept in many copies adds up. Second, and more important if you handle customer data: backups contain personal data. If someone exercises a deletion request under GDPR or similar rules, that data lives in your backups too. Long retention means a longer window where deleted data still exists somewhere.
This is not a reason to keep no backups. It is a reason to pick a defined retention period, write it down, and be able to explain it. "We keep backups for 30 days and they are then deleted" is a clear, defensible answer. "We have backups going back to some point, we are not sure" is not.
The fix: write your retention period into a one-line policy note. What you keep, where, and for how long. You will need it the first time anyone asks a data question.
The setting nobody revisits
Retention gets configured once, usually by whoever built the site, and then never looked at again. Meanwhile the site grows, storage limits get hit, and the tool silently starts pruning older copies to stay under quota. The window shrinks and nothing tells you.
Up Speed runs scheduled off-site backups on every plan, roughly four times a month with 30-day retention and one-click restore. Thirty days is a deliberate choice: long enough to cover a problem you spotted late, short enough that a restore still resembles your current site.
We also test restores quarterly, so the older copies in that window are proven to work rather than assumed to. Most hosts never check.
If you would rather someone else watched the retention window instead of finding out it shrank, the Starter plan covers it from $99 a month per site.