How to Create a Website Backup Schedule in WordPress

Most WordPress sites I look at do have some form of backup running. What they usually don’t have is a real answer to two questions: how far back does the most recent backup go, and has anyone actually tried restoring from one? A backup schedule that nobody has verified is a false sense of security, and it tends to get discovered the hard way — right after a bad plugin update or a hacked site, when it’s too late to fix the schedule instead of just the site.

In my experience, the sites that recover fastest from a disaster aren’t the ones with the fanciest backup plugin — they’re the ones where someone decided on a schedule, wrote it down, and tested a restore at least once. This guide covers how to set that up properly, including a mechanism most backup guides skip entirely: exactly what a backup plugin does and doesn’t capture.

The Two Halves of a WordPress Site, and Why Both Need Capturing

A WordPress site is really two things: the files (themes, plugins, uploads) and the database (posts, pages, comments, settings). Losing either one on its own is bad, but most real incidents — a failed update, a hosting outage, a hacked site, a mistaken bulk-delete — end up affecting both. A proper backup schedule needs to capture the whole site as one consistent set, not just the media library or just the database, or a restore can leave you with content that references files that no longer exist.

There’s a third piece people rarely think about: WordPress core itself (the wp-admin folder, wp-includes, and the root PHP files). Most backup plugins, UpdraftPlus included, deliberately skip backing this up, because core can always be re-downloaded fresh from wordpress.org and re-installing it doesn’t lose anything — your content lives in the database and your uploads folder, not in core. The practical implication: a full disaster recovery on a badly damaged site is usually a fresh WordPress core install plus a plugin restore of your files and database, not a plugin restore on its own. Worth knowing before an actual emergency, not during one.

The other reason a schedule matters more than a one-off backup is timing. If your last backup is three weeks old and something goes wrong today, you’re not just losing the broken thing — you’re losing every post, comment, and setting change from the last three weeks too. For a site that publishes regularly, that gap can mean losing real work, not just convenience. This is exactly the kind of thing that should be checked as part of a routine WordPress security audit, since an out-of-date or untested backup is one of the most common gaps that turns a minor incident into a major one.

Setting the Schedule Up Properly

1. Decide How Often You Actually Need Backups

Match the frequency to how often the site changes, not to what feels safest in the abstract. A blog publishing daily, or an ecommerce store taking orders continuously, needs at least a daily backup — losing a day’s orders is a real business cost. A brochure site updated a few times a year is reasonably safe on a weekly schedule, since there’s rarely more than a small content edit to lose between runs. When in doubt, daily is the safer default — storage for text-and-database backups is cheap, and the cost of guessing wrong the other way is much higher.

2. Choose Where Backups Actually Run

You generally have two options: a backup service built into your hosting plan, or a backup plugin installed on the site itself. A host-level backup (check your hosting control panel — most managed WordPress hosts include this) runs independently of the WordPress install, which means it still works even if the site itself is broken or inaccessible. A plugin-based backup — UpdraftPlus, checked live today at over 3 million active installs, is the most widely used free option — gives you more control over what’s included and where copies are sent, but it depends on WordPress itself running correctly to trigger the backup — not ideal if the site is already in trouble.

Running both at once isn’t overkill — it’s genuinely useful redundancy, since the two methods fail independently of each other.

3. Store Copies Away From the Live Server

A backup stored in the same hosting account as the live site protects you from accidental deletion or a bad update, but not from a server-level failure or a hosting account compromise — if the whole account is compromised, the backups usually go with it. Most backup plugins support sending copies directly to cloud storage (Google Drive, Dropbox, or Amazon S3 are the usual options) as part of the same scheduled run, so this doesn’t need to be a separate manual step once it’s configured.

4. Set a Retention Policy

Keep at least 3–5 recent backups rather than just overwriting the last one each time. This matters because not every problem is noticed immediately — a subtle content issue or a slow-acting malware infection might not surface for a few days, and if your only backup is from after the problem started, it’s already compromised too. Most backup plugins let you set an automatic retention limit so old copies are deleted on their own rather than filling up storage indefinitely.

5. Actually Test a Restore

This is the step almost everyone skips, and it’s the one that matters most. A backup that has never been restored is unverified — the schedule might be silently failing, the files might be incomplete, or the restore process itself might not work the way you assume. Set up a WordPress staging environment and do a full test restore there every few months. It takes half an hour and it’s the only way to know, before an emergency, whether your backups will actually save you — and it’s the moment you’ll discover firsthand whether your plugin restores core files or expects you to reinstall them separately, per the mechanism above.

Practical Tips

• Schedule backups to run during low-traffic hours (overnight, for most sites) so the extra server load doesn’t affect visitors.
• If you’re about to make a significant change — a theme switch, a major plugin update, a redesign — trigger a manual backup first rather than waiting for the next scheduled run.
• Keep a copy of your backup plugin’s restore instructions somewhere outside the site itself (a notes app, a printed page) — if the site is down, you can’t exactly look them up on the site.

Common Mistakes

• Backing up only the database, or only the files. A restore needs both together to actually rebuild a working site.
• Storing backups only on the same server as the site. This protects against almost nothing if the server itself fails or is compromised.
• Never testing a restore. An unverified backup schedule is often discovered to be broken at the worst possible moment — during an actual emergency.
• Assuming a full restore also reinstalls WordPress core. Most plugin-based backups don’t touch core files by design — plan for a fresh core download as part of the recovery process, not as a surprise mid-emergency.

When to Adjust This Baseline

A scheduled backup routine like this is the right baseline for essentially every WordPress site — the frequency and storage location are the only things that should really change based on the site’s size and update cadence. If you’re planning a move to new hosting, a solid backup is also the starting point for migrating WordPress to a new host safely, since the migration process itself relies on having a complete, working copy to move across. And if the worst does happen — a hack rather than just a technical failure — the steps to recover a WordPress website after a security breach depend entirely on having a clean backup to restore from that predates the compromise. For the official reference on backup methods across different hosting environments, the WordPress Advanced Administration Handbook’s backup guide is worth bookmarking.

Backups are one piece of a wider maintenance routine — if you don’t already have one, the step-by-step guide to building a WordPress website covers where this fits alongside updates, monitoring, and the rest of the ongoing upkeep a site needs.

Conclusion

A backup schedule is only as good as its last successful test restore. Set a frequency that matches how often your site changes, store copies off the live server, know exactly what your plugin does and doesn’t capture, and actually try restoring one before you need it for real.