Why Your Hosting Backup Might Not Save You

Short answer: most hosting providers do run daily backups, so the advertising claim itself is usually true. What it does not tell you is whether the restore is fast or ticket-based, whether the backup captures your full database and email alongside your files, how long it is retained, and whether it lives on infrastructure separate enough from your live site to survive whatever took your site down in the first place. None of that is knowable from a features page — it is only knowable by testing it, or by asking very specific questions before you need it.

This guide covers why “daily backups” is a much smaller promise than it sounds, the specific ways hosting backups commonly fail website owners, how to test yours in the next fifteen minutes, and what an independent backup setup should look like alongside whatever your host already provides.

Why do “daily backups” sound safer than they often are?

“Daily backups included” is one of the most common lines on any hosting pricing page, and it is rarely false. The gap is in everything the phrase does not specify: how the backup is restored, what exactly it contains, how long it is kept, and where it is physically stored relative to your live site.

A snapshot taken every day and stored correctly, with a fast self-service restore, is genuinely useful protection. A snapshot taken every day, stored on the same server as the site it is backing up, retained for only a few days, and restorable only by opening a ticket and waiting for a technician, technically satisfies the same marketing phrase — while protecting you far less than the phrase implies. Both scenarios get advertised identically. It is the same gap covered in our piece on why shared hosting emails land in spam: a feature that is technically true on the label, and much less protective than it sounds underneath it.

What are the most common real-world problems with hosting backups?

• Restores are commonly ticket-based, not self-service. Full-account restores are frequently a server administration function rather than something available in a customer’s own control panel — cPanel’s own documentation confirms that full backup restoration is typically a WHM-level task, meaning the account holder cannot always trigger it directly and must wait on support.
• Backups are sometimes incomplete. A website is not just files. WordPress’s own guidance is explicit that a complete backup needs both the database and the files — and email accounts and custom server configuration are frequently left out of what a hosting backup actually captures, even when the plan description simply says “backups included.”
• Retention is often shorter than assumed. Budget shared hosting commonly keeps a handful of days of history, not weeks or months. A problem discovered ten days after it happened can already be past the point where any backup exists to fix it.
• Same-infrastructure storage is a single point of failure. A backup stored in the same data centre, or on the same physical server, as the live site does not protect against the exact failure modes most likely to take a site down — hardware failure, a compromised account, or a provider-wide incident.
• An untested backup is only a belief. This is the least technical point and the most important one. Confidence in a backup and the ability to actually recover with it are two different things, and only testing closes that gap.

What does a proper backup actually need to include?

A complete, restorable backup for a typical business website has four parts, and it is common for a hosting-provided backup to only reliably cover the first one:

• Files — the website’s code, uploaded media, and themes or templates.
• Database — content, users, orders, and settings for almost any modern website or CMS.
• Email — mailbox contents and configuration, if email is hosted on the same account.
• Configuration — DNS records, SSL certificates, redirects, and cron jobs, which are easy to forget and slow to rebuild from memory.

There is also a useful distinction between host-level backups (taken by the hosting provider, of the whole account) and application-level backups (taken by a plugin or tool inside the website itself, such as a WordPress backup plugin). The two are not interchangeable: a host-level backup usually captures more of the account as a whole, while an application-level backup is often more portable, since it is not tied to that specific host and can typically be restored elsewhere. A resilient setup commonly uses both, not one instead of the other.

How do you test whether your backups actually work?

This is checkable directly, and does not require technical expertise beyond following a control panel’s menus. The US government’s own contingency planning guidance, NIST SP 800-34, recommends testing recovery procedures at least annually through an actual restoration exercise — not just confirming a backup file exists.

1. Locate your most recent backup. In cPanel, check the Backup or Backup Wizard section. On other panels, look for “Backups” or “Snapshots.” Note the date of the most recent one.
2. Download a copy before testing anything. Save a local copy of the backup file to your own computer or cloud storage first, so a failed test cannot make your situation worse.
3. Create a low-stakes test target. Use a staging site if your host offers one, a temporary subdomain, or a low-cost test hosting account — somewhere that is not your live site.
4. Actually run the restore. Restore the backup to the test target and confirm the site loads, not just that the restore process reported “success.”
5. Check the specific things that are easy to miss. Log in with a real account, place a test order or submit a form if relevant, check that recent content is present, and confirm email configuration if applicable.
6. Note the date and repeat on a schedule. A backup tested once six months ago tells you less than you think about a backup taken yesterday. Repeat this check every few months, and always after a major site change.

If any step fails — the restore will not run, the site is missing content, or email does not come back — you have just learned something a features page would never have told you, while your site was still safely running.

What should you ask your host about their backup system?

• “Can I restore a backup myself, or does it require a support ticket?” Get a direct answer, not “our support team will assist you.”
• “What exactly is included — files, database, email, and configuration, or just some of these?” Ask for the specific list.
• “How many days or weeks of backup history are retained?” A specific number, not “a good amount.”
• “Where are backups physically stored relative to the live server?” Same rack, same data centre, or genuinely separate.
• “If I need a restore urgently, what is the realistic turnaround time?” Ask for a time estimate, ideally one written into an SLA.

What are better practices and off-site alternatives?

The 3-2-1 backup rule is the standard reference point in backup practice generally: keep at least three copies of your data, on two different types of storage, with at least one copy off-site. A hosting provider’s own backup can reasonably serve as one of those three copies — it should not be relied on as the only one. The US Cybersecurity and Infrastructure Security Agency’s own guidance on backup options makes a similar point about storage media and location diversity.

In practice, an independent copy does not need to be complicated:

• A scheduled download to your own computer or a personal cloud drive — manual, but genuinely independent of your host.
• An object storage service such as Amazon S3 or Backblaze B2 — low-cost, built specifically for storing backups outside any single hosting account.
• An application-level backup plugin (for WordPress and most major CMS platforms) configured to push copies to one of the above automatically, so the independent copy happens without manual effort.

The value of this second copy shows up precisely in the scenario a host’s own backup is worst at surviving: an account-level compromise, a billing dispute leading to suspension, or a provider-side incident affecting the whole server. Our guide on what to do after a website hack covers exactly this kind of recovery scenario, where having an independent backup materially changes how fast a business gets back online.

When is a host’s backup alone not enough?

Run through this list. If two or more are true, an independent backup is worth setting up now, not after something goes wrong:

Cost is rarely the barrier here — for more on evaluating what a hosting plan should guarantee in writing before you buy, including backup terms specifically, see our guide on what to check before you buy hosting, and on the fee side, our piece on hidden hosting charges covers what restore fees can look like when they are not disclosed upfront.

Quick checklist summary

• ✅ Confirm exactly what your backup includes — files, database, email, and configuration
• ✅ Get retention period and restore turnaround time in writing
• ✅ Test an actual restore to a staging site or subdomain, not just confirm a file exists
• ✅ Download an independent copy to your own storage or an off-site service
• ✅ Repeat the restore test every few months and after major site changes
• ✅ If two or more red flags above apply, set up an independent backup this week, not after an incident