Hosting Backup Retention: How Far Back Can You Actually Recover?
Guides / Backup and recovery
Documentation checked: October 5, 2026. Provider examples come from official documentation. The checklists are HRL editorial recommendations; we have not performed a restore test on these providers.
“Daily backups” tells you how often copies are intended to be created, not how far back you can recover. Retention matters when a problem is discovered late. Check the actual available recovery points and the conditions for accessing them before relying on a plan’s backup feature.
Record four different backup facts
| Fact | Question | Evidence |
|---|---|---|
| Frequency | How often should a copy be created? | Documented schedule and completion records |
| Retention | How long do recovery points remain? | Policy and the oldest available usable copy |
| Coverage | What does each copy include? | Files, databases and separately covered services |
| Access | Can authorized people restore or export it? | Supported procedure, permissions and any charges |
The WordPress backup handbook explains that a typical full recovery needs both files and the database. A long retention period does not compensate for a copy missing the component you need. Start with the general backup guide for the coverage inventory.
Check the exact plan and backup type
SiteGround’s Site Tools backup documentation, checked on the date above, lists up to 30 daily copies on shared hosting and up to seven on Cloud. It distinguishes standard and additional premium features, and says the Site Tools instructions do not apply to its Website Builder product.
Kinsta’s backup documentation lists plan-dependent retention. Examples include 14 days for Single 35k visits and 20 days for Single 500k visits. It also gives separate retention for update-related backups. Do not assume every type of backup on an account lasts for the ordinary plan window.
These are documented examples, not provider tests or a guarantee of a particular recovery date. Confirm the applicable subscription and the available copy list inside your own account.
Choose a window around detection as well as activity
HRL recommends considering how long it may take to discover a problem. A broken page noticed immediately and an unwanted content change discovered weeks later need different recovery points.
Hypothetical example: a site keeps only the latest seven daily copies. If an error began ten days before discovery, those seven copies may all contain the error. This is an illustration of a rolling window, not a statement about a named provider’s guaranteed daily completion.
Separately consider how much newer activity a restore would replace. For orders, bookings or memberships, use the order-recovery guide and agree how newer business records would be reconciled. More history and more frequent copies answer different needs.
Do not confuse a download link with retention
Kinsta’s documentation says a generated downloadable archive is available to download for 48 hours and excludes certain dashboard and server configuration. That link window is different from the retention of the host’s ordinary recovery points. Once exported, the copy needs its own storage, access and retention arrangements.
Record where independent copies live, who can access them and when they are removed. A mirror that overwrites yesterday’s files may not provide historical recovery. Test the copy you intend to rely on using the restore-test checklist.
Confirm what happens when service changes
Ask how a plan change, site deletion, suspension or cancellation affects access and retained copies. SiteGround’s Site Tools guide warns that deleting a site removes access to its backups and advises preserving a copy first. Do not make a possible provider recovery service the only exit plan.
Use the cancellation checklist before ending hosting. Verify account ownership and recovery access so the responsible person can obtain the copies when needed.
Before a maintenance release, use the WordPress update checklist to record the selected recovery point, its coverage and the person authorized to restore. A retained backup and an approved rollback procedure are separate parts of the recovery plan.
Choose retention around the detection delay
For a hypothetical unwanted edit discovered on day 18, a seven-day retention policy may no longer hold the earlier copy you need. A longer window helps only if the relevant component was backed up and the retained copy is usable. Estimate plausible detection delay separately from the amount of new data the business can lose, then confirm both available recovery points and the restore procedure.
Keep a dated retention record
Record the backup type, coverage, expected frequency, observed newest and oldest usable points, storage location and last restore rehearsal. Mark any unverified detail as unknown. HRL does not prescribe one retention period for every site; choose it around change frequency, likely detection delays and the recovery process the business can execute. For verified provider-specific retention and export controls, compare the hosting-with-daily-backups shortlist; test any intended recovery workflow using our WordPress backup-restore checklist.