Choose WordPress backup retention around how long a problem might remain unnoticed, then check that your backup schedule produces enough usable recovery points. A setting of “30 backups” is a count, not necessarily 30 days. More frequent backups can shorten the history if you keep the same number of copies.
Shopping for easier backup protection? Compare hosting with daily backups and check the recovery history of the exact plan. Hostinger and IONOS are currently first in this listing. A daily-backup feature saves routine work, but does not tell you how far back you can restore.
Frequency controls the gap between snapshots. Retention controls how far back you can go. Keep both in your overall WordPress recovery plan; changing one does not automatically fix the other.
Thirty copies can mean barely more than a day
Illustrative calculation: assume every backup succeeds, every point is retained, and timestamps are exactly one hour apart. Thirty copies span 29 gaps. The oldest point is therefore 29 hours before the newest one, not 30 days.
| 30 retained copies | Oldest-to-newest span |
|---|---|
| Hourly | 29 hours |
| Every 6 hours | 174 hours, or 7 days 6 hours |
| Daily | 29 days |
These are arithmetic examples, not provider guarantees. Missed jobs, manual points, pruning rules and the age of the latest completed backup change the actual timeline. Check timestamps in the restore list to establish what exists.
Now imagine a broken contact-form integration starts on October 6 and is discovered on October 18. A seven-day daily history cannot reach a point before October 6. A retained October 4 weekly copy might help investigate the old configuration, but restoring the entire database to that date would also roll back later content. Prefer recovering the necessary setting or component on a test site when possible.
Set the window from detection and investigation time
Ask how long it can take to notice missing images, incorrect content or a form that appears to submit but does not deliver. Add time to investigate and preserve a useful older point before automatic cleanup removes it.
- Frequent operational checks: recent, closely spaced copies may be most useful for failed changes.
- Occasional content reviews: keep enough older points to reach before a slowly discovered problem.
- Important milestones: preserve a separate copy before a redesign, migration or major import, subject to your data-handling obligations.
Do not keep every customer-data archive forever by default. Access, storage cost, deletion obligations and the need for useful recovery history all belong in the decision. This is an operational policy, not a substitute for legal retention advice.
Read daily and weekly policies separately
As checked on October 28, 2026, Hostinger’s backup download documentation states that daily backups are retained for seven days and weekly backups for six weeks. It also says a missing date in the list represents a backup that does not exist. Do not assume you can request any arbitrary day within six weeks.
SiteGround’s standard backup documentation lists up to 30 daily copies on shared hosting and up to 7 on Cloud. The words “up to” matter, especially for a new site without a complete history. Verify the points available to your own account.
These examples show different policies, not a recommendation to choose one provider solely by copy count. Restore access, independent export and successful recovery matter alongside retention. Start with hosting plans with daily backups and ask for the policy of the specific package.
Change a retention policy without discarding your safety net
- Inventory first. Record the newest and oldest usable timestamps, what each set contains and where it is stored. Note the timezone displayed in the panel.
- Preserve a milestone copy. Before shortening retention or increasing frequency, export a complete known-good set to private storage and verify that you can retrieve it.
- Adjust frequency and count together. In UpdraftPlus, the Settings tab has separate file and database schedules and retained-copy settings. Check both; a long database history without matching files may not produce the state you need.
- Inspect the result. After the next completed jobs, compare actual timestamps and remaining sets with the intended window. Review warnings and remote-storage usage.
- Test the oldest useful point. Restore it to an isolated environment. A listed date is not proof that the archive is complete or that the site still works.
UpdraftPlus Premium also supports additional rules that thin older backups. Its documentation says these run after ordinary pruning. Do not assume an extra rule saves copies already removed by the primary count. Read the combined policy before relying on it.
If the history is shorter than expected
Stop changing cleanup settings until you know why. Check failed uploads, storage quotas, frequency changes and whether manual copies count toward a limit. Ask the provider whether any additional recovery copy exists, but treat an undocumented copy as unavailable until confirmed.
Raising the retained count today cannot recreate yesterday’s deleted backups. Preserve what remains, repair the process and measure the history as it grows. The policy passes only when it provides the required dates and a usable recovery set, not merely when the settings screen shows a larger number.
Choose enough usable history for the way you check your site. Compare hosting with daily backups and verify the missing detail with the provider before buying.
Cover illustration: cottonbro studio / Pexels.
Sources
Documentation checked October 28, 2026. Product scope and interfaces can change; use the instructions for your current account.