Website Backup Missing or Not Working
You're not sure whether your site has a recent, usable backup — the safety net every other fix on this site assumes exists. "I think the host does it" is not a backup strategy.
Common signs of this issue
- You honestly don't know whether a backup exists — most owners discover the answer during an emergency.
- A backup plugin is installed, but shows errors or hasn't completed a run in months.
- Backups exist but live only on the same server as the site itself.
- Nobody has ever tested restoring one.
- Whoever set up the site 'handled backups,' and that person is long gone.
- You're about to do something risky — an update, migration, or cleanup — and this is the missing precondition.
Safe checks you can do yourself
None of these require sharing passwords with anyone.
- Interrogate your host's backups first: does the plan include them, how often do they run, how far back do they reach, and — the question that surprises people — can you restore them yourself, or only via support tickets (or a restore fee)? The answers live in your hosting panel's Backup section and the plan's fine print.
- Check any backup plugin for the date of its last successful run — installed is not running, and running is not succeeding. Plugins quietly stop after storage fills, credentials expire, or an update breaks them; the error log next to that date tells the story.
- Verify at least one copy lives off the server — cloud storage, or a download on your own machine. A backup stored beside the site shares the site's fate: server failure, account suspension, and hackers take both at once. This one property separates real backups from decorative ones.
- Confirm backups include both halves: the files (theme, plugins, uploads) AND the database (all your content, orders, settings). Some setups capture only one — a files-only backup restores an empty shell.
- Do a restore drill once: restore to a staging copy, or at minimum download a backup and confirm it opens and contains what it should. An untested backup is a hope, not a plan — and the middle of an outage is the worst possible moment to learn yours is corrupt, partial, or three years old.
- Right-size the frequency to how fast your site changes: a static brochure site is fine weekly; a site taking daily orders or posts should back up daily, because the gap between backups is exactly what a restore loses.
What this usually means
Most sites live in one of three states: no backups at all, backups that silently stopped long ago, or backups stored only where a real disaster would destroy them along with the site. The common thread is unverified assumption — "I think the host does it" — which holds right up until the day it's tested by reality. Verifying takes fifteen minutes; the emergency version of this discovery costs the site.
The standard worth meeting has four words: recent, automatic, off-site, tested. Recent enough that restoring loses little; automatic because manual routines die within months; off-site so the backup survives what kills the server; tested so restore-day is a procedure rather than a gamble. Miss any one and the net has a hole exactly where you'll fall.
Backups are also the enabling condition for everything else on this site: nearly every guide says "confirm a backup before changing anything," because the net is what turns risky fixes into reversible ones. A site with real backups fixes problems boldly; a site without them tiptoes — or leaps and sometimes lands badly. It's the cheapest insurance in the entire website world, and the only one that pays out in minutes.
What not to do
- Don't attempt risky work — updates, migrations, malware cleanup, database repairs — before confirming the net exists; that ordering is the whole point.
- Don't rely on a backup you've never tested — corrupt, partial, and files-only backups all look identical to good ones until restore day.
- Don't keep the only copy on the site's own server — the disasters you're insuring against take that copy too.
- Don't treat staging copies, local dev folders, or 'the designer probably has it' as backups — none are recent, automatic, or reliable.
- Don't set up a beautiful system and never look again — backup systems fail silently; a calendar reminder to glance at the last-success date monthly closes the loop.
- Don't restore over a hacked site as the whole fix — the backup may already carry the infection, and the entry point survives regardless (see the hacked-site guide).
When to get help
Setting up the real thing — automatic, off-site, both halves, on the right schedule, with a proven restore — is a small, well-defined job: an hour or two for someone who does it weekly, whether via the host's tools, a reputable plugin, or both together (belt and suspenders is legitimate here). If you take one paid hour of website help this year and have no backups, spend it on this: it's the hour every future emergency will thank you for.
Not sure what to do next?
Answer a few short questions and we'll point you to the safest next step — DIY, a freelancer, or a direct review. No passwords required.
Frequently asked questions
Doesn't my host back everything up?
Maybe — plans vary from excellent daily backups to none at all, retention runs from months to 48 hours, and some hosts charge for restores or exclude backup guarantees in their terms. Verify: schedule, retention, and whether you can restore yourself. Then keep an independent copy anyway.
What makes a backup actually trustworthy?
Four properties: recent (matched to how fast your site changes), automatic (manual routines always lapse), off-site (survives what kills the server), and tested (restored at least once, even to staging). All four, and emergencies become inconveniences.
How often should my site back up?
Match the pace of change: daily for sites taking orders, bookings, or frequent posts; weekly can suffice for static brochure sites. The interval between backups equals the work a restore loses — price it accordingly.
What does a complete website backup include?
Both halves: files (theme, plugins, uploaded images) and the database (pages, posts, orders, settings — the actual content). Verify yours captures both; files-only backups restore a beautiful empty shell.
How do I test a backup without risking the live site?
Restore it to a staging copy (many hosts and plugins support exactly this) and click around. Cruder but useful: download the backup, open the archive, confirm files and a database file are present and recent. Either beats discovering the truth during an outage.
My backup plugin says it's been failing for months. What now?
Common, fixable causes: storage full, expired cloud credentials, or a broken update. Fix or replace it — then, since it failed silently once, add the monthly glance at the last-success date. And take one manual backup right now, before anything else.