Backup Security: Why Your Hosting Backups Might Be Useless When You Need Them

Most people discover their backups are broken at the worst possible moment.

The site goes down. The database is corrupted. The server is compromised. They log into the hosting control panel, find the backup section, click restore, and get an error message. Or they restore successfully and the site is still broken because the backup itself contained the same malware that caused the incident. Or the backup from the day before the problem does not exist because the automated backup job had been silently failing for six weeks.

The feeling of safety that comes from having a backup configured is not the same as actually having a working backup. These are measurably different things, and most site owners do not know the difference until it is too late.

This article covers the six specific failure modes that render hosting backups useless, and how to build a backup system that holds up under real conditions.

Table of Contents

Key Takeaways

A backup stored on the same server it protects is not off-site and can be destroyed alongside the site
A backup that has never been restored is an untested hypothesis, not a recovery guarantee
Malware that lies dormant longer than your backup retention window infects every backup you have
Most shared hosting backup policies are described as a courtesy, not a contractual guarantee
Database backups can complete successfully while missing tables or containing errors that only surface during restore
The restore process itself needs to be tested quarterly, not just the existence of backup files

Failure Mode 1: The Backup Lives Next to the Data It Protects

This is the most common backup failure and the most preventable.

A shared hosting account stores backups in a subdirectory of the same hosting account. The backup file sits on the same physical server as the WordPress files it is supposed to protect. When the server experiences a hardware failure, a catastrophic compromise, or a datacenter incident, the backup disappears alongside the site.

The same problem appears on VPS setups where cron-based backups write to /var/backups/ on the same disk. If that disk fails, both the site and its backups are gone simultaneously.

The 3-2-1 backup rule addresses this directly. Three copies of your data. Two on different storage media. One copy stored off-site, geographically separate from the primary.

Most hosting control panel backups provide one copy in one location. That is a convenience feature, not a backup strategy.

The fix requires actively moving backups off the server. A daily cron job that creates a backup and then uploads it to Backblaze B2, Cloudflare R2, or an S3-compatible bucket satisfies the off-site requirement.

The different storage types available for backup destinations each have different cost and durability characteristics. Object storage for off-site backups costs pennies per gigabyte per month and provides multi-region durability that far exceeds what a local backup offers.

Failure Mode 2: The Retention Window Is Shorter Than the Threat

Most shared hosting plans and many backup plugins default to 7-day or 14-day backup retention. This feels generous until you encounter a threat that exploits the gap.

Modern malware injected through a compromised plugin is often designed to be dormant. It installs itself, waits, and activates later. The purpose is to outlast the backup retention window. Once 7 or 14 days pass, every backup you have contains the infection. The clean version of your site no longer exists in any backup.

Ransomware that targets web servers uses the same logic. It waits until it can identify all accessible backup locations before encrypting everything simultaneously.

A retention policy shorter than the threat dormancy window provides the appearance of backup coverage without the substance.

Practical retention guidelines:

Backup Frequency	Minimum Retention	Why
Daily	30 days	Covers most dormant malware windows
Weekly	12 weeks	Provides quarterly recovery point if monthly backup is unavailable
Monthly	12 months	Covers slow-developing compromises and late-discovered data loss

Keeping 30 daily backups costs far less than most people assume. At Backblaze B2 pricing of $0.006 per GB per month, a 5GB WordPress site with 30 daily backups (with deduplication, actual stored data is often much smaller) costs under $2 per month.

Failure Mode 3: The Untested Restore

A backup file existing is not the same as a backup being restorable. Backup files can be:

Corrupted during creation. A PHP timeout during a large database dump creates a partial SQL file that imports 80% of the data and then fails. The backup tool reports success because it completed the file write. It does not verify that the data is valid.

Corrupted during storage. Bit rot, incomplete uploads to remote storage, or network errors during transfer can all corrupt a backup file without any visible error at the time.

Valid as a file but broken as a restore. Database dumps can succeed while missing certain tables. Archive files can extract while containing files with wrong permissions. WordPress configurations can restore while still pointing to the old database host.

The only way to know a backup is restorable is to restore it. Not to check that the backup file exists. Not to check the file size. To actually extract it, import the database, and confirm the WordPress installation loads correctly.

This is the test almost nobody runs until an incident forces them to. When an incident forces it, any gap in the restore process becomes a crisis multiplier.

Schedule a restore test quarterly. Provision a temporary server, follow your documented restore procedure, and verify the restored site functions correctly. Note the time the process takes and compare it against your recovery time objective. The quarterly test also catches situations where the backup job itself has quietly stopped running.

Backup monitoring using a service like Healthchecks.io provides an automated check: the backup script pings a URL on successful completion, and if the ping does not arrive on schedule, an alert fires.

Failure Mode 4: What Hosting Providers Actually Guarantee

Shared hosting backup policies deserve careful reading before relying on them.

Common language in hosting terms of service:

Backups are performed as a courtesy and are not guaranteed.

We make commercially reasonable efforts to back up your data.

Backups may not be available for all account types.

We do not guarantee backup availability or the ability to restore from backup.

This language is the provider protecting themselves from liability, not describing a reliable backup service. It means you cannot hold them accountable if the backup does not exist when you need it or if the restore fails.

This does not mean hosting backups are worthless. It means they should not be your only backup. A provider backup is a convenience that may help in common scenarios. Your own off-site backup is the safety net for the scenarios where it does not.

Managed WordPress hosting providers often offer stronger backup commitments.

Kinsta provides daily automated backups with downloadable archives and a tested restore process.

Cloudways includes daily backups with a configurable retention period and one-click restore through the dashboard. Even with these providers, maintaining your own independent backup is prudent. No provider guarantee covers every failure mode.

When evaluating a hosting provider, ask specifically: what does the backup SLA guarantee? How long is backup retention? Can you download backup archives directly? What happens to backups if you cancel?

A host without clear answers to these questions has a backup policy worth treating with scepticism.

Failure Mode 5: The Database Backup Is Incomplete

WordPress stores all post content, user data, settings, and plugin configuration in MySQL. The files on disk contain the code. The database contains the content. Both are required for a complete restore.

Incomplete database backups are surprisingly common because the backup mechanism has several failure modes that do not produce obvious errors.

Large tables cause timeouts. The wp_options table can grow to hundreds of megabytes on a plugin-heavy site. A database export that times out at 50% completion writes a partial SQL file. Importing a partial SQL file produces a broken database without a clear error message about what is missing.

The wrong character set creates silent data corruption. If the backup is exported with one character encoding and imported to a database with a different encoding, certain characters are silently replaced. This is especially common for sites with content in languages that use extended character sets.

MyISAM tables need different handling. Some older plugins or WordPress tables use the MyISAM storage engine instead of InnoDB. MyISAM tables can produce inconsistent exports if they are modified during the backup process.

Test database restores specifically. After any database backup, run a row count check:

# On the restored database
mysql -u user -p database_name -e "
SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_schema = 'database_name'
ORDER BY table_rows DESC;"

Compare the row counts against the source database. A table with significantly fewer rows than the source indicates a partial import.

Failure Mode 6: Malware in the Backup

A backup containing malware restores the malware alongside the content.

This scenario plays out when a site is compromised, the compromise is not detected promptly, and multiple backup cycles pass before the incident is discovered. Every backup since the compromise was created contains the infection.

Restoring from any of these backups restores a site that is still compromised. The malware reactivates, the site gets flagged again by Google, and the cycle repeats.

The fix has two components:

First, scan for the initial infection point before restoring. Identify how the compromise occurred. If it was a vulnerable plugin, remove that plugin before restoring. If it was a stolen credential, rotate all passwords and API keys before restoring. Restoring without removing the initial access vector means the site will be recompromised.

Second, scan backup files before restoring them. A malware scanner run against the backup archive before extraction can identify obvious infection. Wordfence, Sucuri, and similar tools can scan a WordPress installation on disk after extraction but before the web server serves it.

For serious incidents, restoring from a backup that predates the suspected compromise window is more reliable than scanning a known-infected backup. This requires having backup retention long enough to reach a pre-infection state.

What happens during and after a server compromise, including the decision tree for whether to restore or rebuild, is covered step by step in the server crash recovery guide.

Building a Backup Strategy That Holds

A working backup strategy has three properties. It runs automatically without manual intervention. It stores copies off the server it protects. It gets tested before an incident forces the test.

The backup script with monitoring:

#!/bin/bash
set -euo pipefail

DATE=$(date +%Y%m%d-%H%M)
SITE_DIR="/var/www/yourdomain.com"
DB_NAME="wordpress_db"
DB_USER="backup_user"
DB_PASS="your_password"
BACKUP_DIR="/tmp/backups"
BUCKET="your-bucket-name"

mkdir -p $BACKUP_DIR

# Database backup
mysqldump -u $DB_USER -p$DB_PASS \
  --single-transaction \
  --quick \
  --lock-tables=false \
  $DB_NAME | gzip > $BACKUP_DIR/db-$DATE.sql.gz

# Files backup
tar -czf $BACKUP_DIR/files-$DATE.tar.gz \
  --exclude="$SITE_DIR/wp-content/cache" \
  $SITE_DIR

# Upload to object storage using rclone
rclone copy $BACKUP_DIR remote:$BUCKET/daily/

# Clean up local temp files
rm -f $BACKUP_DIR/db-$DATE.sql.gz $BACKUP_DIR/files-$DATE.tar.gz

# Confirm success to monitoring service
curl -fsS "https://hc-ping.com/YOUR-UUID" > /dev/null

The final curl to Healthchecks.io only executes if every previous command succeeded. set -euo pipefail at the top ensures the script exits immediately on any failure. If the script exits early, the ping never fires, and Healthchecks alerts you.

Using Restic for encrypted deduplicated off-site backup:

Restic provides encryption at rest, deduplication across backup versions, and native integration with most object storage providers. Daily incremental backups of a 5GB WordPress site typically transfer less than 50MB after the initial backup.

# Initialise the repository
restic -r s3:https://s3.us-west-000.backblazeb2.com/bucket init

# Run backup
restic -r s3:https://s3.us-west-000.backblazeb2.com/bucket backup /var/www/yourdomain.com

# Verify integrity
restic -r s3:https://s3.us-west-000.backblazeb2.com/bucket check

# Prune according to retention policy
restic -r s3:https://s3.us-west-000.backblazeb2.com/bucket forget \
  --keep-daily 30 \
  --keep-weekly 12 \
  --keep-monthly 12 \
  --prune

Frequently Asked Questions

Is my hosting provider’s daily backup enough?

For low-stakes sites with easily reproducible content, provider backups are often sufficient if they are tested. For sites with real business value, transaction data, or content that took significant effort to create, provider backups should be treated as a first layer rather than the only layer. The reasons are practical: provider backups can be deleted when you cancel, they are subject to the courtesy language rather than contractual guarantees, and they are typically stored in the same data centre. Adding your own off-site copy costs very little.

How do I know if my backup job is actually running?

The most reliable method is monitoring the backup job completion with an external service. Set up a free account at Healthchecks.io, create a check with your expected schedule, and add a curl ping to the end of your backup script. If the script fails silently or stops running, the missing ping triggers an email alert. Checking the backup log file manually is less reliable because it requires remembering to check and interpreting the output correctly.

What should I do if every backup I have is infected?

Start with a clean installation rather than restoring from an infected backup. Install WordPress fresh on a new server or clean hosting account. Import only the database, after scanning it for injected content. Do not restore the wp-content/themes or wp-content/plugins directories from backup. Download fresh copies of all plugins and the theme from official sources. Import only the uploads directory, after scanning it for PHP files that should not exist there. This process takes longer than a backup restore but produces a genuinely clean site.

How large will my backup files actually be?

A typical WordPress blog with moderate media is 1 to 5GB for files and 100MB to 500MB for the database. A large WooCommerce store with product images can be 20 to 50GB for files and 1 to 5GB for the database. Deduplication tools like Restic reduce the cumulative storage of 30 daily backups to roughly 1.2 to 1.5 times the single backup size for sites with stable content. At Backblaze B2 pricing, 30 days of deduplicated daily backups for a 5GB site costs under $1 per month.

What is the minimum backup retention I should keep?

Thirty days of daily backups is the practical minimum for most production WordPress sites. This covers most dormant malware windows and provides enough granularity to restore to a specific date around a known incident. Add weekly backups retained for twelve weeks for a quarterly recovery point, and monthly backups retained for a year for longer-horizon recovery needs. The additional storage cost for the weekly and monthly backups is minimal because they overlap significantly with the daily backup content.