A website backup is a copy of two separate things: the files that make up your site, and the database that holds its content. Almost every backup failure traces back to that one sentence — either half of it was never being copied, or nobody ever checked whether the copy would go back.
The call is rarely “we got hacked.” It is usually “we ran the plugin updates and now the whole site is a blank white page,” or “someone deleted the wrong page and emptied the trash.” Both of those are five-minute problems if a good backup exists and a two-week problem if one does not.
What is actually inside a website backup
A complete backup has two halves, and they live in different places on the server.
- The files. Your theme and any child theme, every plugin, everything in the media library, and any custom code. These sit on disk.
- The database. Every post and page, your users and their passwords, site settings, menus, orders if you sell something, and form submissions if you store them. These are rows in database tables, not files you can see over FTP.
Restore one without the other and you get a site that does not work. Files alone give you a clean install wearing your theme with no content in it. A database alone gives you all your text pointing at images that are not there.
So the first question to ask about any backup system is the dullest one: does it copy both halves, and how far back do the copies go?
What backups actually protect you from (hackers are fourth on the list)
In order of how often I see each one:
- A bad update. A plugin update collides with another plugin, or with the version of PHP the server is running, and the site throws a fatal error. This is the single most common reason anyone needs a backup.
- Human error. A page gets deleted, a homepage gets overwritten with a draft, a bulk edit catches more posts than intended.
- Something failing underneath you. A corrupted database table, a server migration that goes sideways, or a hosting account suspended over a credit card that expired while someone was on vacation.
- A compromise. Real, worth planning for, and still the least frequent of the four.
That ranking matters because it changes what you optimize for. A backup is an undo button far more often than it is a disaster recovery plan, and an undo button needs to be fast and recent, not just thorough.
Your host’s included backups are a courtesy, not a guarantee
Nearly every hosting plan now advertises daily backups, and most owners reasonably assume that settles the question. Then you read the actual policy. Nexcess, to pick one host that publishes its terms plainly, keeps 30 days of what it calls free daily courtesy backups, recommends that customers “maintain their own backups and use a deeper history than 30 days,” and states that clients “assume ultimate responsibility for data integrity, retention, security, backup, and ownership.”
That is not a host being cagey. It is an accurate description of what an included backup is good for, and it has three practical limits:
- Retention. Thirty days is plenty for a bad update you notice Tuesday. It does nothing for slow damage — a page quietly deleted in February and discovered in June is simply gone.
- Same-vendor risk. If the problem is the hosting account itself, the backups inside that account may go with it.
- Granularity. Host backups usually restore the whole site. Rolling back one deleted page by reverting everything also reverts the four blog posts and nine orders that came in since.
Use the host backup as the fast path. Keep one copy that is yours.
How often should you back up your website?
Match the frequency to how much work you are willing to redo. A brochure site that changes a few times a year is genuinely fine on a daily backup with 30 days of retention. A site that takes orders, bookings, or form submissions needs its database copied far more often than its files — hourly or near-real-time for the database, daily for the files — because records pile up between snapshots while the theme and plugins sit unchanged for weeks. Separately from any schedule, take a manual backup immediately before every update, migration, or redesign launch. That is the backup most likely to be needed inside the hour.
A backup you have never restored is a guess
This is the part that gets skipped, and it is the part that decides whether any of the above was worth paying for. A backup file that exists is evidence of a successful upload. It is not evidence of a successful restore.
Restore to a staging site — not over your live site — and walk through it. Once a quarter is a reasonable floor, plus once before any major change. Check five things: the site loads without errors, images resolve in the media library, a form submits and the email arrives, you can log in, and the most recent content you remember publishing is actually there.
What counts as a passing test depends on how the site is built, which is why “does the homepage load” is a weak check. On the Las Campanas Realty site I built in Santa Fe in partnership with Monsoon Design, the content lives in three custom post types — listings, neighborhoods, and team members — and the property listings arrive from the local MLS feed rather than being typed in. A real restore test there asks whether the custom post types came back with all their fields intact and whether the feed reconnects, because a homepage can render perfectly while the structured content behind it is empty.
Write down how long the restore took. That number is your actual recovery time, and it is usually longer than anyone guessed.
Where the copies live matters more than how many you have
The old 3-2-1 rule still holds up: three copies of the data, on two different kinds of storage, with one of them somewhere else entirely. For a small-business website that usually means the live site, the host’s daily backup, and a copy in a cloud storage account you control.
The offsite copy is the one people cut, and the ransomware numbers argue against cutting it. In Sophos’s State of Ransomware 2025 survey, 94 percent of organizations hit by ransomware said the attackers tried to compromise their backups during the attack, and 57 percent of those attempts succeeded. A backup sitting on the same server, reachable with the same password, is not a second copy. It is part of the same thing you are trying to recover from.
One copy somewhere the website itself cannot reach, with its own credentials, solves most of this.
The part nobody writes down
A backup is only as useful as someone’s ability to find it under pressure. Put four lines in a document your team can actually get to:
- Where the backups are, and who has the login.
- Which tool or host feature makes them, and how far back it keeps them.
- Who to contact at the host, and what the support hours are.
- How long the last tested restore took.
I have been handed sites where the backups were running flawlessly to a cloud account nobody still had the password for. The copies were perfect and completely unreachable.
A reasonable setup, in four lines
- Daily files, more frequent database if you take orders or submissions.
- One copy offsite, with credentials the website does not have.
- A manual backup before every update or launch.
- A restore test on staging once a quarter, with the elapsed time written down.
That is an afternoon of setup and about twenty minutes a quarter after that. It is cheap compared to rebuilding content from a search engine cache, which I have also done, and would rather not do again.
Patrick Iverson is a brand strategist and custom WordPress developer in Santa Fe, New Mexico, and has run an independent practice here since 2001. If you are not sure what your site’s backups cover or whether anyone has ever tested them, that is a short conversation and a good one to have before you need the answer.
