The backup strategy that actually saves you

Almost every clinic site I audit has backups. Almost none of them have backups that would actually work in a real disaster. A WordPress backup strategy that survives a 3 AM emergency is a different thing from a backup plugin that runs nightly.

This is not a gotcha. The owners aren’t careless. The backup plugin runs on schedule, the dashboard shows green checkmarks, and the email confirmations arrive. But the gap between “a backup ran” and “this backup will restore my site at 3 AM on a Sunday when the server is on fire” is wider than most people realize.

What most clinics call their WordPress backup strategy

The typical setup is a WordPress plugin like UpdraftPlus, BackWPup, or BlogVault, configured at some point in the past, dumping a backup to either the host’s filesystem or a cloud destination like Google Drive or Dropbox. The schedule is usually daily for the database, weekly for files. The retention is usually “keep the last seven backups, then delete the oldest.”

If you have this, you are ahead of about 30% of small business sites that have nothing at all. So congratulations. The rest of this post is about why that setup probably has gaps.

Three failure modes I have actually seen

The backup is on the same server as the site. If the server gets compromised, the backups get compromised. If the host has a billing problem and the account is suspended, the backups are inside the suspension. I have seen a site lost this way: the host froze the account over a payment issue, the backups were in /home/user/backups, and the only copy of the site was inside the account the owner couldn’t access for ten days.

The backup hasn’t been tested. The dashboard says the backup ran. The file is sitting in cloud storage. Nobody has ever tried to restore it. When the day comes and the restore fails (corrupted archive, missing file, plugin can’t decrypt its own output, you name it), the discovery happens at the worst possible moment. A backup you haven’t restored from is a backup you don’t have.

The backup excludes something important. Default plugin configurations sometimes skip the uploads folder to save space, or exclude certain tables to reduce database size. If you don’t read the configuration carefully, you end up with a “complete” backup that is missing all the media files. The site restores, but every image is broken. I have unwound this exact situation for two different small practices.

The 3-2-1 rule, applied to a small practice

The classic backup rule is 3-2-1: three copies of the data, on two different storage types, with one copy offsite. It was developed for serious disaster recovery and assumes enterprise budgets. For a small clinic site, you can scale it down without losing the spirit.

The version I run for clients looks like this:

Copy 1: The live site. Obviously. Counts as one copy.

Copy 2: A nightly snapshot on the same server. A nightly database dump plus rsync of wp-content to a backups directory on the same machine. This is fast, free, and useful for the most common failure mode (someone edited a page wrong and wants yesterday’s version). Retention: seven days, rolling.

Copy 3: A weekly offsite archive. Once a week, a script (or a plugin if you prefer) bundles the database and files into a single encrypted archive and uploads it to a cloud storage service in a different account from your hosting provider. I use Cloudflare R2 for most clients. Backblaze B2 is also fine. The cost is a few dollars a month. Retention: keep the last four weeks plus a monthly snapshot for the past year.

That gives you three copies, two storage types (server disk plus object storage), and one offsite. It is not enterprise-grade. It will recover a small practice site from any realistic failure mode I have encountered.

The restore test

This is the part everyone skips. Once a quarter, I take the most recent offsite backup and restore it to a staging environment. Not the live site. A separate subdomain, a separate database, a copy of the production environment that lets me confirm the backup actually contains a working site.

The first time you do this, something will be wrong. The database will reference URLs that no longer exist. A plugin will throw fatal errors because of an environment difference. The .htaccess file will have hardcoded paths from the old server. You will learn what your actual disaster recovery process looks like, in a low-pressure environment where the only consequence of failure is that you fix it before the next quarter.

After the second or third quarterly test, the restore becomes routine. That is the whole point. The first time you restore from backup should never be in an actual emergency.

What to back up that isn’t WordPress

If your site uses anything outside the WordPress database, your backup plan needs to cover that too. Common examples I see on clinic sites:

• Appointment data stored in a third-party booking service. The data lives in their system, but you should still have an export schedule that pulls a CSV or JSON copy weekly.
• Form submissions sent to email or a CRM. If submissions only live in inboxes, those inboxes are part of your backup plan.
• DNS records. Export your DNS zone to a text file once a quarter. If you ever lose access to your DNS provider, you will want the records to rebuild from.
• Server configuration. Nginx config, PHP-FPM pool settings, systemd unit files. If you rebuild the server, what is the recipe? Write it down, store it with the backups.

The honest minimum

If you take nothing else from this post: have one backup that lives somewhere other than your web host, and restore from it at least once a year. That single practice puts you ahead of most small business sites I audit.

Everything else, the rolling retention, the encrypted archives, the quarterly tests, is incremental improvement on that foundation. None of it matters if the backup and the site live on the same server, and none of it matters if the restore has never been tested. Start there. The rest is engineering.

If you want help putting this in place for your practice, that is the kind of work covered under the maintenance side of our Plans. It pairs naturally with the 18-month rule: quarterly maintenance is also when you confirm the backups still work.