Most website owners believe they have backups. Considerably fewer have backups that would actually restore a working site, and almost nobody finds out which group they are in until the day it matters. The gap is rarely about whether backups are running. It is about what they include, where they live, and whether anyone has ever tried using one.
A backup you have never restored from is not a backup. It is an assumption with a filename.
Primo Collab
The four things a complete backup includes
A website is not one thing, and a backup that captures only part of it restores only part of your site.
- The database. Your posts, pages, products, orders, customers, settings, and most plugin configuration. Without this you have a working design and no content.
- Files and uploads. Images, PDFs, and anything in your media library. These are often the largest component and the most commonly excluded to save space.
- Themes and plugins. Including customizations. If a developer edited a theme file directly, that change lives here and nowhere else.
- Configuration. Server settings, redirect rules, and environment configuration. Frequently forgotten and frequently the reason a “successful” restore does not work.
Miss any one of these and a restore leaves you with a site that is technically back but practically broken.
Frequency should match how often you would lose work
The right schedule is not a universal answer. It follows from a single question: how much work are you willing to redo?
| Site type | Reasonable frequency | Why |
|---|---|---|
| Brochure site, rarely updated | Weekly | Little changes between backups |
| Blog publishing regularly | Daily | A lost day is a lost post |
| Ecommerce store | Hourly or continuous | Every gap is real orders and customer records |
| Membership or booking site | Hourly or continuous | Gaps mean lost signups and reservations |
For any site taking orders, daily is not enough. A backup from last night means every order placed today is gone, and those are transactions with real customers waiting on them.
Where backups live matters as much as what is in them
A backup stored only on the same server as your website solves almost nothing. The most common serious failures, server compromise, hosting account issues, and ransomware, take the backup with the site.
The practical standard is straightforward:
- At least one copy stored somewhere other than your hosting account.
- More than one restore point retained, because problems are often discovered days after they started.
- Access to the backup that does not depend on the site being up.
That last point catches people. If your backups are managed through a plugin in your WordPress admin, and your site is down hard enough that you cannot log in, you need another route to those files.
Retention: how far back should you be able to go
The instinct is to keep recent backups only. The problem is that many issues are discovered late. A malware injection, a broken plugin update, or a content deletion can go unnoticed for a week or more, by which point every recent backup contains the problem.
A workable pattern is layered: several daily restore points, a few weekly ones, and a monthly copy going back a few months. This costs very little in storage and it is the difference between having options and having only the compromised version.
The test almost nobody runs
Here is the uncomfortable part. Backup software reports success based on whether the backup file was created. It does not verify that the file would restore into a working site. Corrupted archives, incomplete database exports, and missing file permissions all report as successful backups.
The only way to know is to restore one, into a staging environment, and click around. Once a quarter is enough. The first time you do it you will usually find something, and finding it on a Tuesday afternoon is considerably better than finding it during an outage.
A reasonable setup for a small business site
- Automated backups covering database, files, themes and plugins, and configuration.
- Frequency matched to how much work you would lose.
- Stored off your hosting account.
- Layered retention: daily, weekly, monthly.
- A quarterly test restore into staging.
- Documented restore steps, written down somewhere you can reach when the site is down.
The mistake to avoid
Assuming your host handles it. Many hosts do take backups, and many of those are intended for their own disaster recovery rather than for restoring your individual site on request. Some charge for a restore. Some retain only a few days. Some cover the database but not your uploads. It is worth finding out exactly what your host provides, in writing, before you need it rather than during the phone call where you find out it does not cover your situation.