Somewhere in your inventory there is a line that reads "backups: handled by host." It may be true. This week's check exists to find out, because a backup nobody has opened is a rumor, and Security Month is a poor time to be relying on a rumor.
The question this check answers is the one every other post this month quietly assumes has a good answer. If your website vanished this afternoon, whether hacked, corrupted, or deleted by an honest mistake, could you put it back, and how much recent work would be missing when you did? The donation page, the event calendar, last week's form entries: all of it depends on a copy someone can actually open.
Most organizations have never asked the question out loud. The check takes about fifteen minutes, touches nothing the public can see, and ends with a dated line in a log. Either answer is useful today.
Why backups fail quietly
Backup systems rarely announce their failures. The scheduled job stops running after a platform update. The backup captures the site's files but not its database, which is where the pages and form entries actually live. The archive turns out to be corrupt. The "complete" copy is missing the uploads folder that holds ten years of photos. Every one of those problems is invisible until someone tries a restore, which is why the restore test, not the backup itself, is the real unit of protection.
There is also a custody problem worth naming. Your host's backups live inside the same account as your website. If that account is suspended, over a billing dispute, a compromise, or the host's own failure, the backups are suspended with it. The standard worth adopting is the 3-2-1 rule: three copies of your data, on two different types of storage, with one copy somewhere your host does not control.
The 15-minute version
A restore test does not mean overwriting your live site. The gentlest version takes about fifteen minutes.
Log in to wherever your most recent backup lives: the host's backup panel, a backup plugin such as UpdraftPlus, or the organization's Google Drive or Dropbox folder.
Download the latest backup to your computer.
Open the archive. Confirm two things are inside: the site's files (look for an uploads or media folder with recent images) and a database file, usually ending in .sql or .gz.
Check the dates. The newest backup should be recent enough that losing everything after it would be survivable. For a site taking orders or donations, that means daily; for a site that changes monthly, weekly is reasonable.
Write down where every copy lives, and whether one of them sits outside the host's account.
If your host offers a one-click staging site, the stronger version restores the backup there and confirms the site actually comes up with recent content present. Plan an hour for that the first time; it drops to about twenty minutes once you know where everything is.
What you might find
Most people find one of three things. The backup is fine. The backup exists but is missing the database or is weeks old, which is a setting to fix this week. Or there is no copy outside the host, which means adding an independent backup to Google Drive or Dropbox is next week's project. None of these findings is a crisis today. Each would be one during an incident.
Done looks like a dated entry in your log: the backup's date, what was inside, where every copy lives, and your initials. Repeat it each quarter. Four entries a year is the whole discipline, and it is the difference between a backup and a plan.
Get the log. The M4.1 Backup Verification Log has a line for every quarterly test, with a sign-off column, because a name on a log changes how carefully the test gets run. It is free with a Web Managers account at https://webmanagers.com/register, it is the worksheet for Episode 5, and it arrives with the weekly Web Managers letter.