Web Hosting Backups Explained: What Your Host Isn't Telling You

Every hosting plan advertises backups. "Automatic daily backups" appears on almost every pricing page. What those pages rarely tell you is how long those backups are kept — and that distinction is the difference between recovering from a disaster and losing your website permanently.

This guide covers what backups actually are, the critical difference between a backup plan and backup retention, the silent-corruption trap that catches experienced developers off guard, and the insider cPanel tips that let you recover correctly when something goes wrong.

What Is a Backup?

A backup is a point-in-time snapshot of your website's data. For most websites, that means two separate things:

• Files: Your website code, themes, plugins, uploaded images, configuration files — everything stored in the filesystem.
• Database: Your content, users, settings, orders — everything stored in MySQL or MariaDB.

This distinction matters because files and databases are backed up separately, and they can get out of sync. Restoring your files without restoring the database to the same point in time — or vice versa — often produces a broken site. A WooCommerce store's files from Tuesday combined with its database from Monday will have plugin code that doesn't match the database schema. You'll see errors, missing data, or a white screen.

Backup Plan vs Backup Retention: The Difference That Costs Sites

These two terms describe different things, and conflating them is one of the most common — and costly — misunderstandings in web hosting.

Backup plan (also called backup schedule or backup frequency) refers to how often a new snapshot is taken: hourly, daily, weekly. This is the number hosts advertise.

Backup retention refers to how many snapshots are kept and for how long before being deleted. This is the number hosts bury in their documentation — or don't publish at all.

A concrete example

Host A runs daily backups with 7-day retention. On any given day, you can restore to any of the past 7 days. That's a genuine restore window.

Host B also runs daily backups — but with 3-day retention. You have 3 restore points. On day 4, the oldest backup is deleted to make room for the newest one. Despite "daily backups" sounding equivalent, Host B's window is less than half of Host A's.

Host C runs weekly backups with 4-week retention. You have 4 restore points, but they're spaced 7 days apart. If something breaks on Thursday and the last backup ran Sunday, you're restoring to a version that's 4 days old — losing 4 days of content.

The number to ask for: how many restore points do you keep, and what is the oldest one?

The Silent-Corruption Problem: Why Timing Destroys Your Restore Options

This is the scenario experienced developers rarely anticipate until it happens to them.

Imagine your WordPress site is compromised on a Monday. The attacker doesn't immediately deface it — that would be too easy to notice. Instead, they install a backdoor, inject hidden links, and wait. You don't notice anything unusual. Your site looks and behaves normally.

Ten days later, Google Search Console sends a security alert. You open your site and see the damage. You go to restore from backup — and discover that your host keeps 7-day retention. Every stored backup was taken after the Monday compromise. Every one of them contains the backdoor and injected content. There is no clean version to restore from.

This scenario plays out in several forms:

• Security breaches with delayed discovery: The most common. Attackers deliberately wait before activating malicious code.
• Dormant plugin bugs: A plugin update corrupts the database in a way that only surfaces under specific conditions — high traffic, certain user roles, specific product combinations. You might not notice for weeks.
• Gradual data corruption: A bad database query that runs on a schedule slowly corrupts rows over time. By the time you notice, every backup contains partial corruption.
• Bad deployments in staging-less environments: A developer pushes code that breaks an edge case. The bug isn't caught immediately. Three weeks later someone reports it. By then, the retention window has closed.

The professional standard for production websites is 30-day retention minimum. For sites handling financial transactions or medical data, 90 days. Most shared hosting plans offer 7 days or less. This mismatch is where sites are lost.

What Good Backup Coverage Looks Like

A robust backup strategy combines frequency, retention, and storage location:

One critical detail most cheap hosts omit from their marketing: on-server backups are not real backups. If a host stores your daily backup on the same server that runs your site, and that server's disk fails or the datacenter has a power event, you lose the site and the backups simultaneously. Offsite backup — stored in a separate datacenter, or in a cloud storage service like S3 or Backblaze — is what separates a backup from a snapshot.

cPanel Insider Tips: How to Actually Restore Correctly

cPanel is the most widely deployed hosting control panel, and it's the interface most site owners use to manage backups. These are the things that catch people out.

Full account backup vs partial restore

cPanel distinguishes between a full account backup and individual component restores. When something goes wrong, the instinct is to restore everything. This is often the wrong move.

If your database was corrupted but your files are fine, restoring the full backup overwrites your current (working) files with the older version, potentially introducing regressions you'd already fixed. cPanel lets you restore just the database — or just a specific database — from a backup archive. Use partial restores when only one component is affected.

Under Backups → Restore in cPanel:

• Home Directory: Restores all files. Use only if files are the problem.
• MySQL Databases: Restores a specific database. Use when content is corrupt or missing.
• Email Forwarders / Filters: Restores email routing. Rarely needed for site recovery.

Download your backup before the retention window closes

This is the most important cPanel tip that almost no one knows until they need it: you can manually download a full cPanel backup as a `.tar.gz` file and store it yourself. If your host keeps 7-day retention and you've just discovered a problem that started 5 days ago, download the 5-day-old backup immediately before it rolls off the retention window.

In cPanel → Backup Wizard → Download a Full Website Backup: this packages your home directory, databases, email configuration, and DNS zone into a single archive. Store it on your local machine or in cloud storage.

This is also your insurance against switching hosts — before cancelling your old account, download a full backup.

JetBackup vs native cPanel backups

Many hosts install JetBackup alongside or instead of cPanel's native backup tool. JetBackup offers a significantly better interface: per-file and per-database restore granularity, restore to a different location before overwriting live data, and a restore preview. If your cPanel has a "JetBackup" menu item, use it instead of the native Backup section — the capabilities are meaningfully better.

The key JetBackup feature to know: Restore to a different destination. Instead of immediately overwriting your live site, you can restore a backup to a temporary directory, verify it looks correct, then manually swap it in. This eliminates the risk of a bad restore making your situation worse.

The "backup of a backup" problem

Some hosts run cPanel's built-in backup tool, which creates backup archives in your home directory — and then back up that home directory (including the archive) as part of their server-wide backup. This sounds like double protection, but the archive in your home directory counts against your disk quota. More importantly, if something goes wrong with the server's backup system, the cPanel archive is your last line of defense — and it's on the same machine as your site.

If you see a large backup-YYYY-MM-DD.tar.gz file in your cPanel file manager, that's a cPanel-generated archive. Download it locally and then delete it from the server (it's consuming your disk quota). Do not rely on it as your only external backup.

The Restore Mistakes That Break Sites

Even with good backups, restoration errors are common. These are the mistakes that turn a recovery into a second disaster.

Restoring files without the matching database

The most frequent mistake. Your files and database were taken at different times, so they represent different states of your application. A WordPress site with plugin files from Tuesday and a database from Monday will crash if the plugin ran a database migration between Monday and Tuesday. Always restore both to the same point in time.

Restoring to live without staging first

If you're not certain a backup is clean — because you suspect the corruption window may reach earlier than you think — restore it to a staging environment first. Spin up a subdomain (staging.yourdomain.com), restore the backup there, scan it for malware, verify the content is correct, then overwrite live. Restoring a compromised backup over a clean site makes the situation worse, not better.

Not checking the backup date before restoring

cPanel's restore interface can be ambiguous about which date a backup corresponds to. Confirm the backup timestamp before initiating a restore. A restore from the wrong date can overwrite recent legitimate changes with older content — you've now lost data in both directions.

Forgetting to update DNS and SSL after host restore

If you're restoring to a new server or hosting account (not just restoring files on the same server), DNS records and SSL certificates are not included in the backup. After restoring files and databases, you'll need to re-point your domain's nameservers or A records, and re-issue SSL certificates. Sites commonly go down for hours after a successful restore because this step was overlooked.

The Plugin Layer: Why You Shouldn't Rely Solely on Your Host

Hosting backups are infrastructure-level — they protect you from server failures, host-side errors, and catastrophic loss. But they are not granular enough for content-level protection, and they are controlled entirely by a third party.

For WordPress sites, a second backup layer via a plugin provides restore points your host doesn't:

• UpdraftPlus: The most widely used. Backs up to Google Drive, Dropbox, S3, or SFTP on a schedule you control. Free tier covers the basics; paid adds incremental backups and multisite support.
• WP Time Capsule: Incremental backups — only changed files and database rows are backed up after the first run. Extremely efficient for large sites. Stores to Dropbox or Google Drive.
• Jetpack VaultPress / Jetpack Backup: Real-time backups (every change triggers a backup) and one-click restore. Strongest for high-traffic ecommerce where daily snapshots lose too much data.

The key principle: your backup destination should be somewhere your host cannot access and a server failure cannot destroy. Google Drive, Dropbox, and S3 are controlled by you, not your host. Even if your host's entire infrastructure fails, your backup is intact.

What to Ask Your Host Before Trusting Their Backups

These are the questions that reveal whether a host's backup offering is real or marketing copy:

1. How many restore points do you keep, and how far back does the oldest one go? — "Daily backups" is meaningless without the retention number.
2. Where are backups stored? — Same server = not a backup. Same datacenter = partial protection. Separate datacenter or cloud = genuine offsite backup.
3. Are files and databases backed up together at the same timestamp? — If they're backed up on different schedules, restoring both to the same point in time may not be possible.
4. Can I restore myself through cPanel/JetBackup, or do I need to open a support ticket? — Requiring a ticket adds hours of delay when every minute counts.
5. Is there an additional charge to restore? — Some hosts charge per-restore. Kinsta, for example, includes restores in the plan; some shared hosts bill separately.
6. Are backups included in my plan, or are they an add-on? — Hostinger's Business plan and above include automated backups; their cheapest plan does not. SiteGround's entry plan includes daily backups with 30-day retention. The details differ significantly by plan and provider.

Summary

The backup conversation in web hosting is dominated by frequency — "daily backups" — and almost completely ignores retention, storage location, and restore mechanics. These are the factors that determine whether your backup is useful when you need it.

The practical checklist:

• Know your host's retention window — not just their backup frequency
• Confirm backups are stored offsite, not on the same server
• Verify files and databases are backed up at matching timestamps
• Run a second backup layer (UpdraftPlus or equivalent) to a destination you control
• Before any major change, download a manual cPanel full-account backup locally
• Practice a restore on a staging environment before you need to do one under pressure

A backup you've never tested is a backup you don't have. The only way to know a restore works is to run one.