The Shared-Hosting Backup Reliability Checklist

1. Pre-backup checks

Before you trust a backup schedule, confirm the basics once by hand: the job actually completed (not just started), the archive size looks right for your site’s content, and the log shows a success — not a silent partial upload. On shared hosting, a job that “ran” and a job that “finished” are not the same thing; strict PHP time limits kill plenty of backups midway without ever surfacing an error in wp-admin.

• Does the backup log show every phase — database, files, archive, upload — as complete?
• Is the archive size in the ballpark you’d expect for your uploads folder and database?
• If you use remote storage, did the upload confirm at the destination, not just locally?

2. The offsite rule

A backup stored on the same server as the site it protects is not a backup — it’s a copy that dies with the original. Hosting account suspensions, disk failures, and one misconfigured cleanup script all take the local copy down with the site. Keep at least one destination that is not the hosting account itself: FTP/SFTP to a different host, an S3-compatible bucket (Amazon S3, Cloudflare R2, Backblaze B2), or a downloaded local copy on your own machine.

• Does at least one backup destination live outside this hosting account?
• If the answer is no, is that because of cost — R2 and B2 both have free tiers worth checking?

3. Restore-drill cadence

The only way to know a backup works is to restore it. Not read the log, not check the file size — actually restore it somewhere and look at the result. A quarterly drill against a staging copy (or a throwaway local install) catches the failure mode that never shows up any other way: an archive that uploads cleanly but was silently corrupted, or a database dump missing a table because a plugin changed its schema.

• Has this site’s backup ever actually been restored, even once, since it was set up?
• Is there a recurring reminder — quarterly is a reasonable default — to do it again?

4. Disk headroom

Shared hosting plans cap disk space, and backups compete with the live site for that same quota. A backup job that fills the last of the quota can fail the archive step, block the site from writing new uploads, or leave stale partial archives behind that eat space without protecting anything. Check your retention settings actually prune old backups, and leave real headroom — not just enough for today’s backup, but enough for the site to keep growing between now and your next check.

• Does your retention policy delete old backups automatically, or does it rely on you remembering?
• Is there enough free disk headroom for at least one more full backup than you currently keep?

Turning this into something automatic

This checklist describes what “a backup that works” actually requires — most of it is policy and habit, not software. BackupRidge handles the parts a plugin can: resumable backups tuned to your host’s real time limits, unlimited offsite destinations free (SFTP, S3, R2), automatic retention pruning, and — on Pro — scheduled backup verification, which automates check 3 above by test-restoring on a schedule instead of leaving it to memory.