Every site owner I talk to says the same three words when backups come up: “We have backups.” Then I ask the follow-up question, and the room goes quiet. Where are they? How far back do they go? Who has restored one? Nobody knows, because nobody has ever had to find out.
A backup you have never restored is not a safety net. It is a belief. The difference shows up on the worst possible day, usually while someone is on the phone with a customer who cannot check out.
I have been building and taking over WordPress sites since 2006, and the pattern repeats almost without variation. The backup system has been running for two years. Then we try to restore one, and something is missing: the database but not the uploads, the files but not the database, or a copy from this morning that already contains the problem we are trying to undo.
Here is how to find out which kind you have, before it matters.
What “we have backups” usually turns out to mean
When I audit a site I just inherited, the backup situation falls into one of four buckets.
The first is a host-level snapshot. Most hosts take one. It is better than nothing, and it is rarely what you think it is. Some hosts keep a day, some keep a week, and some keep a whole server snapshot that only their support team can unpack, on their schedule, which may not be the next twenty minutes.
The second is a plugin running inside the site. This is the common one. A plugin writes a backup archive and stores it, and what decides whether it will save you is where it stores it. If the archive sits in a folder on the same server as the site, a server failure takes the site and the backups in one move. If the archive goes to cloud storage that somebody still has the password for, you are in much better shape.
The third is a backup configured once by someone no longer involved, pointing to a storage account nobody can log into. The emails still arrive. The success notices still say success. The destination has been full since March.
The fourth is no backup at all, which is oddly the easiest to fix, because nobody is operating on a false assumption.
The four questions a backup has to answer
Forget the dashboard for a minute. A backup is only real if you can answer these four questions out loud.
What is in it? A WordPress site has two parts: a database that holds your pages, posts, settings, orders, and users, and a set of files that holds your images, uploads, theme, and plugins. You need both. A database-only backup restores a site that points to images that no longer exist. A files-only backup restores a beautiful empty shell.
Where does it live? Somewhere that is not the server running your site. That is the whole point. If the answer is “on the site,” you have a copy, not a backup.
How far back does it go? This matters more than people expect. Not every disaster announces itself. A bad plugin update breaks the checkout, and you notice in ten minutes. A content problem, a broken form handler, or a quiet redirect loop can run for two weeks before anyone reports it. If your retention is seven days, a two-week-old problem has no clean version to go back to.
Who can put it back, and how long does it take? This question separates a plan from a hope. If the only person who knows the process stopped working with you in 2023, you do not have a restore path. You have a research project with the clock running.
How to test a restore this week
A restore test takes an hour, and it is the single highest-value hour you can spend on a site you depend on. Do it on a copy, never on the live site.
- Find the most recent backup and write down its date and time. If you cannot find it in ten minutes, that is your finding. Stop here and fix that first.
- Confirm it contains both halves. Open the archive listing or the backup plugin’s record and look for a database file and an uploads folder. Both should be in the same set, from the same run.
- Stand up a staging copy. Most decent hosts offer one-click staging. If yours does not, a local environment on your own machine works fine for a test.
- Restore the backup into that copy. Not into production. Nothing you do in the next step should touch the live site.
- Walk the site like a customer. Load the homepage. Load a service page. Check that images appear rather than showing broken placeholders. Submit the contact form. If you sell something, add it to the cart and get to the payment step.
- Check the back end too. Log in. Look at your posts and pages. If you run a store, confirm recent orders are present, and the customer records came with them.
- Write down how long the whole thing took. That number is your real recovery time, and it is the number to tell your team when they ask how bad an outage would be.
If every step passes, you have a backup. Put a reminder in the calendar and move on with your life. If any step fails, you have just learned it on a Tuesday with no customers waiting, the cheapest way to learn.
The mistakes I watch people make
Trusting the success email. Backup plugins report that they finished writing a file. They don’t report whether the file can be read or whether the destination had room. A truncated archive reports success and restores nothing.
Keeping backups on the site. It feels tidy, and it fails in exactly the scenario backups are meant to prevent: backing up only the database. This happens when somebody optimizes for storage cost. It is the most common half-measure I find, and it produces the most convincing-looking restore, right up until you scroll past the first image.
Restoring straight into production. When something is already broken, the instinct is to push the backup over the live site immediately. Do that with the wrong archive, and you turn one problem into two, and the second has no backup. Restore to a copy, confirm, then promote.
Set it up once and never look at it again. Hosts change storage providers. Passwords rotate. Plugins get deactivated during troubleshooting and never get turned back on. A backup system isn’t something you install; it’s something you check.
How often to actually test
Twice a year is enough for a small site that does not change much. Quarterly is right for most business sites. Test again after any migration, host change, or major plugin overhaul, because those are precisely the moments when a backup chain quietly breaks and reports nothing.
The test does not have to be elaborate. One hour, one staging copy, one walk through the site as a customer. The value is in having done it once knowingly rather than once in an emergency.
Where this fits
Care plans are for backups, updates, monitoring, and the boring routine checks that keep a site boring. Ours start at $200 a month and are listed on the services page, alongside everything else we scope up front. The point of a care plan is not that nothing ever goes wrong. It is that when something does, there is a tested copy and a person who already knows the restore path.
If you want to know where your site actually stands, send us your host and backup plugin name through the contact page and ask for a backup check. We will tell you, in plain language, what your current setup would and wouldn’t survive before you spend a dollar with us.