Here is a question most WordPress site owners cannot answer on the spot: how many copies of your site exist right now, where are they, and who could delete them? Not "do you have backups." Almost everyone says yes to that. The harder question is which copies exist, what is in each one, and which of them would still be there after a bad day.
Copies pile up over the life of a site. The host makes some on its own. A backup plugin makes more. Someone downloads a zip before a redesign. A migration leaves an export file behind. A developer keeps a local copy on a laptop. A few of these are real protection. Some are useless. Some are a security problem. You cannot tell which is which until you write them all down. This article walks through how to build that list, what to record for each copy, and how to judge the result.
Start with the copy you did not make: your host's
The first entry on almost every inventory is the backup your hosting company takes automatically. Many owners have never looked at it closely. So the natural first question is: doesn't the host's backup already cover the basics?
It helps to know that "host backup" can mean several different things. On some plans it is a nightly copy of your whole account that you can browse and restore from a control panel. On others it is a disaster-recovery snapshot the host keeps for its own use, which you can only reach by asking support. Some hosts include backups on every plan, while others sell them as an add-on, and a few offer both a free basic tier and a paid tier with longer history. Two sites on the same host can have quite different coverage just because they are on different plans.
Sometimes the host's backup does cover the basics, for everyday accidents. But the details vary far more than people expect. How many days are kept, whether there is a size or file-count limit, whether you can download a copy, and what happens to the copies if the account lapses all differ by host and by plan. Before you write "host backup: yes" on your list, look up the real terms. BackupYourSite keeps a recently checked breakdown of how host backups compare across SiteGround, GoDaddy, Kinsta and others, which is a useful reference for the questions to ask. BackupYourSite's host comparison, checked in November 2026, found automatic retention ranging from one day to ninety days depending on the host and plan. That is a big enough spread that "my host does backups" tells you almost nothing on its own.
Then go and check your own control panel. Count the copies that are actually there, and note the date of the oldest and the newest. That is your first real line in the inventory.
Why an inventory works better than a backup plan document
Plenty of businesses have a backup plan written down somewhere. It says what should happen: daily backups, stored offsite, tested quarterly. An inventory is different. It records what is actually happening, today, on this site.
The two drift apart over time. A plan written when the site launched does not know about the staging copy added last spring, the storage account that changed hands when a contractor left, or the old hosting account that was cancelled after a migration. An inventory forces you to look at the current state, and that is where the surprises are.
It also changes the conversation. "Are we backed up?" invites a quick yes. "Show me the list of copies and what each one survives" invites an honest answer.
Step 1: Find every copy
Set aside an hour per site the first time. Go through each of these places and write down anything you find. Do not judge anything yet. The goal is a complete list.
The host's automatic backups
Covered above. Note the plan name, the retention you can actually see in the panel, and whether a download option exists without buying an add-on.
Backup plugin or service archives
Open your backup tool and look at where it sends files. Many plugins keep a local copy on the server as well as sending one to remote storage. Some keep local copies by default and only send remote copies if you configured it. Write down each destination separately, because a local archive on the server and a remote archive in cloud storage are two very different things.
Cloud storage folders
Log in to each cloud storage account the site has ever been connected to: Google Drive, Dropbox, OneDrive, S3-compatible buckets, SFTP servers. You may find folders from a previous plugin you stopped using, or archives from years ago. Note the account each one sits in, and who has the login.
Staging and development copies
A staging site is a full copy of your site. So is a local development install. They are not backups in the usual sense, because they change and are often out of date, but they are copies, and in a real emergency people do restore from them. Write them down, with a note on how current each one is.
Downloads on personal machines
Ask everyone who has worked on the site whether they have ever downloaded a backup or a database export. Designers, developers, the person who ran the last migration. These copies are often the oldest and the least protected, sitting in a downloads folder or on an external drive.
Migration leftovers and old hosting accounts
If the site has moved hosts, check whether the old account still exists and still holds data. Look for export files left in the site's own directory after a migration. Migration tools sometimes leave archives in folders that are reachable from the web.
Stray database dumps
Search the server for files ending in .sql, .sql.gz, .zip or .tar.gz, especially inside the web root. A database dump in a public folder is not protection. It is a file anyone could download if they guess the name, and it contains every user record on the site. Note these on the list with a clear flag, because they need to be dealt with.
Step 2: Record seven facts about each copy
Once you have the list, fill in the same details for every entry. A simple spreadsheet works. These are the columns that matter:
1.Where it lives. Which server, service or device holds the file.
2.Who controls that account. Not who uses it day to day, but whose login and email it belongs to. A business account, a personal account, a client's account, the host's account.
3.Who pays for it. Which card or invoice keeps the storage alive. If two copies are paid for by the same card, write that down.
4.What it includes. The database, the uploads folder, themes and plugins, wp-config.php, server settings such as .htaccess or web server rules, email. Many copies cover some of this, not all of it.
5.How far back it goes. The oldest restore point available, and how often new ones are made.
6.How you would restore from it. One click from a panel, a manual upload, a support ticket, a plugin that must already be installed. And roughly how long it would take.
7.What could delete it. The account being suspended, someone with admin access, a retention rule, a failed payment, a laptop being lost or wiped.
Column four is where most people get their first surprise. A database-only export, for example, will bring back posts and pages but not a single image. Column seven is where the second surprise comes from, because it is the column that shows how many copies are exposed to the same risk.
Step 3: Run each copy through a few bad days
Now test the list against real events. For each scenario below, go down the inventory and mark which copies would still exist and still be usable afterwards. Be strict. "Probably" counts as no.
A bad update breaks the site
The easy case. Almost every copy survives this, including the host's backups and local plugin archives. If your inventory fails here, something basic is wrong.
Someone gets admin access to WordPress
An attacker with wp-admin access can see the settings of every plugin, including your backup plugin, and anything the plugin can reach. If a storage connection is managed from inside WordPress, ask whether that access lets someone delete remote archives. Local archives on the server are almost certainly reachable. Host backups held in the host's own system usually are not, unless the attacker also has the hosting login.
The hosting account is suspended or closed
A failed payment, a dispute, an abuse report on a shared server, or a client who cancels without telling their developer. Many hosts tie backups to an active plan. Mark every copy that lives inside the hosting account, including local plugin archives and the host's own backups, as gone in this scenario. What remains is your real offsite protection.
A compromise is found six weeks late
Not every problem shows up on day one. Injected spam links, a hidden admin account or a malicious redirect might sit unnoticed for weeks. In this scenario, only copies older than the infection are clean. Look at column five. If every copy on your list is less than a month old, none of them helps.
The person who set up the backups leaves
Mark every copy tied to that person's own accounts or devices as at risk. If their personal Google account holds the archive folder, or their laptop holds the only old copies, those go with them.
A laptop is lost or a personal drive fails
Copies on personal machines disappear, and worse, they may now be in someone else's hands. This scenario matters for privacy as well as recovery.
When you are done, look at which copies survive every scenario. On many sites the honest answer is one copy, sometimes none.
Step 4: Count by independence, not by number of files
The 3-2-1 rule is the usual yardstick: three copies of your data, on two different types of storage, with one copy kept offsite. It is a sound rule. The mistake is in how people count.
Ten archives in the same Dropbox folder are not ten copies in any useful sense. They share one account, one password, one bill and one point of failure. The same goes for a host snapshot and a plugin archive that both sit inside the same hosting account. For counting purposes, copies that would disappear together count as one.
Using your inventory, group copies by what could delete them, from column seven. Each group that can fail independently counts as one copy. Then check:
Three: do you have at least three independent groups, counting the live site as one?
Two: is at least one copy on a different kind of storage from the live server's disk?
One: is at least one copy outside the hosting account entirely, with a login and a bill that the hosting side cannot touch?
If you want a deeper treatment of how each digit maps to the parts of a WordPress install, BackupYourSite has a thorough piece on the 3-2-1 rule tested against an actual WordPress stack, including a short self-check. Your inventory gives you the raw facts to answer it honestly, which is the part most people skip.
Government security guidance often goes further than 3-2-1. CISA's ransomware guidance, for example, recommends keeping offline, encrypted backups and testing them regularly. For a WordPress site, that translates into two practical additions: at least one copy that cannot be deleted from the site or the hosting panel, and a restore that has actually been tested rather than assumed.
What most inventories turn up
Every site is different, but a handful of findings come up again and again once people do this exercise properly.
Lots of copies, all in one place
The most common result. The host keeps daily copies, the plugin keeps local archives, and that feels like plenty. Then the "account suspended" scenario wipes out every entry. The site has many copies and one failure domain.
The offsite copy shares a login or a card
The site does send archives to cloud storage, but the storage account is the same Google account used for the hosting panel, the domain registrar and the site's admin email. Or the same company card pays for everything. That copy is offsite in location but not in control. One compromised login or one expired card can reach it.
Copies nobody knows how to restore
An archive in an old format from a plugin that is no longer installed. A host backup that can only be restored by opening a support ticket. A storage folder whose files nobody has ever opened. Column six often reveals that the restore path depends on a tool or a person that is no longer around.
Copies that cover only part of the site
Database-only exports, file-only downloads, backups that skip wp-config.php or server configuration. Each on its own is a partial copy. Restoring from it brings back part of the site and leaves you rebuilding the rest by hand.
Retention that is too short for slow problems
If the oldest restore point on the whole list is a week or two old, the late-discovery scenario has nothing to fall back on.
Copies that are a liability
Stray database dumps in web folders, old site exports on personal laptops, archives in a former contractor's cloud account. These do not protect you. They expose user data. The inventory is a good moment to delete what you do not need, as well as to add what you are missing. If your site holds customer data, keeping unmanaged copies around is a risk in its own right.
Fixing the gaps, in order of value
Once the inventory shows where you stand, fix things in this order. The early steps give the most protection for the least effort.
8.Remove dangerous copies. Delete database dumps and archives from web-accessible folders. Ask former team members to delete local copies, and move any archives held in personal accounts into an account the business controls.
9.Get one copy truly outside the host. If nothing survives the "account suspended" scenario, this is the biggest gap. It needs its own account, its own strong password with two-factor login, and ideally a separate payment method.
10.Make sure that copy is complete. Database, uploads, themes, plugins, configuration. A full copy beats several partial ones.
11.Extend retention to cover slow problems. Decide how far back you might realistically need to go, then make sure at least one copy reaches that far.
12.Protect the offsite copy from the site itself. If an attacker with wp-admin access could delete it, look at ways to separate the two, such as storage with versioning or deletion locks, or a backup method that does not keep its storage credentials inside WordPress.
13.Test a restore from each important copy. Pick the offsite copy first. Restore it to a staging site or local install, and click through. Record the date in the inventory.
You do not need to do all six in one week. Even the first two put most sites in a much better position than they were before the inventory.
Keeping the inventory alive
An inventory is only useful while it is current. It goes stale the same way the old plan document did, just more slowly, because you will be looking at it regularly.
Review it on a schedule
Quarterly is a sensible rhythm for most sites. Re-check the newest and oldest restore point for each copy, confirm the account owners have not changed, and note the date of the last test restore. It takes far less time than the first pass.
Review it after certain events
Some changes should trigger an update straight away:
A move to a new host or a new hosting plan.
A change of backup tool or storage provider.
Someone with access joining or leaving the team.
Creating or removing a staging site.
Any security incident, even a minor one.
Keep it somewhere that survives the site
The inventory itself should not live on the site or in the hosting account. A shared document in a business account, or a printed copy for small operations, is fine. The point is that you can read it when the site is down.
A template you can copy
If a blank spreadsheet feels like a slow start, use this layout. One row per copy, one column per fact, plus a few columns for the scenario test. Here is how a single row might read for a typical host backup. The values are an illustration of the format, not figures for any particular host.
Copy: Host's automatic daily backup.
Where it lives: Inside the hosting control panel.
Who controls the account: The hosting account owner (write the actual name of the business or person).
Who pays: Same card as the hosting plan.
What it includes: Files and databases for the account. Check whether email is included.
How far back: The oldest date you can see in the panel today.
How to restore: From the panel, whole site or selected files.
What could delete it: Account suspension, plan cancellation, the retention window rolling forward.
Survives bad update: Yes. Survives hacked admin: Usually. Survives account suspension: No. Survives late discovery: Only if the window is long enough.
Fill in a row like that for each copy and the gaps show up on their own. A column of "No" under account suspension is the clearest signal you will get that you need a copy somewhere else. Add a final column for "last test restore" and leave it blank until you have actually done one. Blank cells are honest, and they tell you what to do next.
For agencies and freelancers: the portfolio view
If you look after several client sites, run the same inventory for each, then put them side by side. A single sheet with one row per site and columns for "offsite copy exists," "offsite copy is independent of the client's hosting account," "oldest restore point" and "last test restore" makes weak spots obvious at a glance.
The portfolio view also shows patterns you will not see one site at a time. You might find that every site on a particular host relies only on that host's backups, or that a dozen sites send archives to the same personal account set up years ago. Those are single points of failure across your whole client list.
It is also a useful document to share with clients. Many clients assume their site is backed up because "the developer handles it." Showing them a plain list of where copies live and what each survives sets expectations honestly, and it makes the case for any extra protection without overselling.
One more thing to record for client sites: who holds the hosting account. If the client owns it and pays for it, you may not hear about a lapsed payment until the site is offline. That single fact often decides whether an independent offsite copy is optional or essential.
The short version
Most backup advice starts with what tool to use. An inventory starts with what you already have, and that is usually more revealing. List every copy of your site, including the ones you did not make on purpose. Record where each lives, who controls it, who pays for it, what it includes, how far back it goes, how you would restore it and what could delete it. Then run the list through a few bad days and count only the copies that fail independently.
The result is rarely as comfortable as "we have backups." It is far more useful. It tells you exactly which gap to close first, it gets rid of copies that put user data at risk, and it gives you a document you can hand to a colleague or a client that says, plainly, how this site would come back if things went wrong. An hour spent on that list now is an hour you will not spend searching for a usable backup in the middle of an incident.
