Support
Support

Match RPO/RTO to Regular WordPress Backups for Agencies, Hourly DB

The minimum viable setup is an automated plugin backup of your database and files, an offsite copy stored outside your host, and a host-level snapshot for fast rollback, together satisfying the 3-2-1 rule. Match your backup frequency to how often the site’s data changes, and treat an untested restore as no backup at all.

TL;DR:

  • Regularly test restore processes by restoring backups to a staging environment to verify their integrity and identify potential issues before recovery is necessary.
  • Store at least three copies of backups across two different media types, including an offsite location, to prevent single points of failure and ensure data safety.
  • Set backup schedules based on each site’s data change frequency, such as hourly for WooCommerce stores and daily for most other sites, while retaining 30 to 50 days of backup history.
  • Use a combination of plugin backups, host snapshots, and offsite cloud storage with encryption, avoiding reliance solely on a single method or local storage.
  • Never ignore failure notifications or skip pre-update backups, as these process lapses significantly increase the risk of data loss during site emergencies.
Wpcto
Make WordPress Support Less Disruptive
WPCTO handles ongoing WordPress support and maintenance, so your agency can stay focused on creative and strategic client work.

Visit WPCTO

Table of Contents

What to back up: database, wp-content and configuration files

A WordPress backup that skips either half of the site is not really a backup. The database holds every post, page, user account and, on WooCommerce sites, every order and customer record, which makes it the highest-value target in any restore scenario. Lose it and you lose the business logic of the site, not just its appearance.

Files matter just as much, because the database means nothing without the code and media that render it. Priority order for file backups looks like this:

Two mistakes crop up constantly here. Agencies back up cache directories that add bulk for no benefit, since caches rebuild automatically. And they let a media library balloon for years without a storage strategy, until the nightly backup job times out before it finishes. WordPress’s own backup documentation confirms there is no built-in backup utility, which is exactly why the plugin and storage decisions below carry so much weight.

How often should you back up a WordPress site?

Backup frequency should be set by two numbers, not habit. Your recovery point objective (RPO) is how much data you can afford to lose, measured in time since the last good backup. Your recovery time objective (RTO) is how long you can afford to be down while you restore.

Those two numbers point to very different schedules depending on the site:

Retention matters as much as frequency. Keep at least 30 to 50 days of backup history so you can roll back past a slow-burn problem, not just yesterday’s mistake. Agency best practice for 2026 recommends this window specifically because many hosts trim their own snapshot retention to seven or fourteen days, which is rarely enough to catch an issue that was introduced weeks earlier and only noticed later.

Automatic backups: how plugins actually work

Most WordPress backup plugins follow the same basic model: they compress your database and files into an archive, then push that archive to a remote storage destination on a schedule. It works well for small to mid-sized sites, and it’s the reason a plugin like UpdraftPlus has become a default choice, supporting scheduled pushes to Google Drive, Dropbox and Amazon S3 straight out of the free version.

The model has real limits, though. Archive-and-upload jobs can hit PHP memory or execution time limits on larger sites, and a job that dies partway through can leave a corrupted archive that only reveals itself when you try to restore from it.

Pro Tip: Before trusting any backup plugin on a media-heavy site, check its behaviour on large archives specifically. A plugin that works flawlessly on a 2GB site can silently fail at 20GB, and you often won’t find out until the day you need the restore.

Do host snapshots replace plugin backups?

No, and treating them as interchangeable is one of the more expensive mistakes an agency can make. Host-level snapshots, offered by most managed WordPress hosts, are genuinely fast: many restore a full site within minutes, which is hard to beat for rolling back a bad deployment.

The catch is where they live. A host snapshot sits on the same account as the live site, so if that account is suspended, compromised or the hosting relationship ends abruptly, the backup disappears with it. That’s a single point of failure hiding inside what looks like a safety net.

Where should you store WordPress backups?

The 3-2-1 rule solves the single-point-of-failure problem: keep three copies of your data, across two different media types, with at least one copy stored offsite. For a WordPress site, that typically means the live site itself, a host snapshot for fast rollback, and a third, encrypted copy in cloud storage the agency controls independently of the hosting account, a structure the 3-2-1 rule was designed around long before WordPress existed.

For that third copy, Google Drive and Dropbox are the easiest to set up and work fine for smaller agencies. Amazon S3 and Cloudflare R2 offer more control and lower storage costs at scale, which matters once you’re managing dozens of client sites rather than one. Managed backup vendors bundle storage with monitoring, which suits agencies that don’t want to build their own pipeline.

Whichever you choose, encrypt the archive, keep the storage credentials separate from your hosting login, and never let a personal or shared team drive become the primary offsite copy. Backup guidance for 2026 is direct on this point: the agency, not the client and not the host, should own that offsite account.

How do you test that a backup actually works?

An untested backup is a theory, not a safeguard. The only way to know a backup will save you is to restore it somewhere that isn’t the live site and see what happens.

  1. Spin up a clean staging environment, separate from the production site entirely.
  2. Pull the backup archive and restore both the database and the files into staging.
  3. Run integrity checks — wp db check confirms the database imported cleanly, and wp core verify-checksums confirms WordPress core files match the official release.
  4. Smoke-test critical flows: log in as an admin, place a test order if it’s WooCommerce, submit a contact form.
  5. Record the elapsed time and compare it against your RTO target for that site.

Run this drill quarterly for a single important site, or rotate through a full portfolio monthly if you’re managing several client sites, a cadence backed by documented restore-drill steps used at agency scale. Watch for the three failures that show up most often: a database that imported but is missing recent tables, an uploads folder that restored partially, and file permissions that block the site from loading even though every file is technically present.

Pro Tip: Time every restore drill with a stopwatch, not a guess. Agencies routinely discover their real restore time is triple what they’d assumed, which only becomes obvious once a client’s site is actually down and the clock is running for real.

Hands-on checklist: set up regular WordPress backups today

You can have a genuinely reliable setup running within an hour.

  1. Choose your cadence for database and files separately, using the RPO guidance above (hourly database for WooCommerce, daily for most other sites).
  2. Configure your backup plugin or managed service, then connect a remote storage destination that isn’t tied to your hosting account.
  3. Enable encryption, failure alerts and a retention policy of at least 30 days so a backup job silently failing doesn’t go unnoticed for weeks.
  4. Run one manual backup now, then restore it to a staging environment to confirm the whole chain actually works before you rely on it.

Build in a pre-update habit too: trigger a manual backup and confirm it completed before any core, theme or plugin update, since updates are when things break most often. Once the schedule is running, check the backup logs weekly and put a monthly restore test on the calendar, not just an occasional one when something feels off. Our guide on how to backup your WordPress website properly walks through the plugin configuration side of this in more depth.

Database vs files: why you need both

Treating the database and the files as one undifferentiated “backup” is where a lot of agencies get caught out. They behave completely differently, change at different rates, and fail in different ways when something goes wrong.

The database is dynamic. Every comment, order, form submission and settings change writes to it, which is exactly why a WooCommerce store needs hourly database backups while its theme files might not change for months. It’s also comparatively small and fast to back up, which is why frequent database-only backups are cheap to run even on sites where a full file backup would be too heavy to do hourly.

Files, by contrast, are large and mostly static. A media library might be gigabytes in size but change only when new content is published. Files are also where the site’s actual functionality lives: the theme rendering every page, the plugins powering every feature, the custom code holding client-specific logic together.

The failure modes diverge too. Restore only the database and you get correct content sitting inside a broken or outdated theme, with missing plugin functionality. Restore only the files and you get a fully functional site running with stale or completely absent content, orders and users. Neither half-restore is usable on its own, and a genuinely reliable process backs up both on their own appropriate schedules and restores them together as a matched pair, not independently.

Database and file backup comparison

Backup formats and restore compatibility

Not every backup format restores the same way, and this catches agencies out most often when they’re forced to switch tools mid-emergency. Most plugins export the database as a .sql file and wrap files into a .zip or proprietary archive, and while .sql is close to universal, proprietary archive formats often only restore cleanly through the same plugin that created them.

That has a practical consequence: if a plugin’s licence lapses, the company shuts down, or you simply switch tools. An archive in that plugin’s proprietary format can become difficult or impossible to open. A plain .sql database dump alongside a standard .zip of files is the safest long-term format precisely because it doesn’t depend on any one vendor staying in business.

PHP version compatibility matters too. A backup taken on PHP 8.1 will generally restore fine to a PHP 8.2 environment, but restoring an old backup onto a much newer PHP version can expose deprecated function calls in old plugins that quietly broke somewhere along the way. Always check the destination environment’s PHP version against the site’s requirements before restoring, not after.

Character encoding is the quiet one that trips people up. A database exported with the wrong charset settings can corrupt special characters, accented names, or non-Latin text on import, which is a strong reason to include a database integrity check as a mandatory step in every restore, not an optional one.

Common pitfalls that undermine WordPress backups

Most backup failures aren’t dramatic. They’re small, quiet gaps that only surface the day a restore is actually needed.

Most of these are process failures, not technology failures. The tools generally work; the discipline around using them consistently is what usually breaks down first.

How to secure backup files from unauthorised access

A backup file is, in effect, a complete copy of your site including user data, and in WooCommerce’s case, customer and order information. Securing that file matters as much as securing the live site itself, arguably more, because a backup often sits somewhere with weaker monitoring than production.

Encrypt backup archives at rest, not just in transit. Most managed storage destinations, including Amazon S3 and Cloudflare R2, support encryption by default, but it’s worth confirming rather than assuming.

Never store backups inside a publicly accessible directory on the same server. A default WordPress backup path sitting inside /wp-content/uploads/backups is a well-known target, and search engines have been known to index files left there by misconfigured plugins.

Keep offsite storage credentials separate from your WordPress admin and hosting logins. If an attacker compromises the site itself, credentials stored inside wp-config.php or a plugin’s settings shouldn’t also hand them the keys to every historical backup.

Apply least-privilege access to whoever can retrieve backups. Not every team member needs the ability to download a full site archive containing customer data, and limiting that list reduces both accidental leaks and insider risk.

Finally, set an automatic expiry on old backups rather than letting them accumulate indefinitely. Beyond your retention window, old backups are pure liability: they hold ageing personal data with diminishing operational value, and every extra copy is another surface an attacker could target.

Setting up UpdraftPlus and Jetpack Backup: quick walkthroughs

UpdraftPlus starts with installation from the plugin directory, then a settings screen where you choose your schedule for files and database separately, which matters because they can run on different cadences. Connect a remote storage destination under the “Settings” tab, choose from options including Google Drive, Dropbox or Amazon S3, and authorise the connection. Run one manual backup immediately after setup to confirm the connection works before trusting the schedule.

Jetpack Backup takes a different approach, running as a real-time backup service rather than a scheduled archive job, which suits sites where every transaction or comment matters and a once-daily snapshot would leave too large a gap. Setup runs through connecting the site to a WordPress.com account, then choosing a plan tier based on storage needs. Because it backs up continuously, there’s no schedule to configure, though it’s still worth confirming restore access and reviewing what’s included before relying on it for a client site.

For larger site portfolios, host-level snapshot tools (available through most managed WordPress hosts) usually need only a toggle in the hosting dashboard to enable, with frequency and retention set from a dropdown. They’re the fastest to configure but, as covered earlier, should sit alongside a plugin backup rather than replace one. Our agency guide to choosing a WordPress backup approach covers how to weigh these options against a client portfolio’s actual risk profile, and a comparison of WooCommerce-focused backup plugins is worth a look if you’re managing several stores with different transaction volumes.

Setting up UpdraftPlus and Jetpack Backup: quick walkthroughs — overview diagram

Agency perspective: the real cost of unmanaged backups

Every agency owner underestimates the true cost of backups until the week a client site goes down at 6pm on a Friday. The restore itself might take an hour. The unbillable hours around it, chasing down which backup is actually good, testing a restore for the first time under pressure, explaining the delay to a furious client, routinely cost far more than the incident itself.

That’s the hidden maths agencies rarely put in a proposal: backups feel free until the moment they aren’t, and that moment always arrives at the worst possible time. A white-labelled managed service turns that unpredictable cost into a fixed, recurring one, with tested restores already proven before an emergency, not during it.

Before deciding whether to build this in-house or hand it off, it’s worth seeing what unmanaged support hours are actually costing you across your client base. The WordPress Profit Calculator puts a number on that in under 90 seconds.

— Marcel

How Wpcto handles backups so your team doesn’t have to

A fully managed backup and restore layer can sit behind your agency, invisibly, so your client relationships stay yours while the 6pm Friday emergency becomes someone else’s problem, not your account manager’s.

Wpcto

That means scheduled, monitored backups mapped to each site’s actual RPO, restores that have already been tested before they’re ever needed, and security monitoring that catches problems before a client notices them. Everything ships white-labelled, so it reads as part of your service, not a subcontractor’s. It’s built into our broader WordPress support services, alongside performance optimisation, hosting management and emergency support for the moments a backup alone can’t fix.

For agencies weighing whether to staff this internally or hand it to a specialist partner, our Creative Clinic support option is worth a look, and for client sites holding sensitive data, our enhanced security service pairs directly with a solid backup regime. Start by running your numbers through the WordPress Profit Calculator to see what uncaptured revenue is sitting in your current client base, then get in touch about handing the backup burden to us.

Sources

FAQ

How do I back up my entire WordPress site?

Back up the database and the wp-content folder together, using a plugin like UpdraftPlus or a managed host snapshot, then push a copy to offsite storage you control so it survives even if the hosting account is lost.

What is the best WordPress backup solution?

There isn’t a single best option for every site: UpdraftPlus suits scheduled archive-based backups for most standard sites, Jetpack Backup suits sites needing real-time protection, and host snapshots add fast rollback on top of either.

How do I manually back up WordPress?

Export the database through phpMyAdmin or WP-CLI, then download the wp-content folder along with wp-config.php via FTP or your hosting file manager, keeping both copies together as a matched pair.

Can I back up my WordPress site locally?

Yes, a local backup on your own computer or network drive works as one of your three copies under the 3-2-1 rule, but it should never be the only copy, since it doesn’t count as a genuine offsite backup.

How often should WordPress backups run?

Frequency should match how fast the site’s data changes: daily for brochure and blog sites, twice daily for membership sites, and hourly database backups for active WooCommerce stores.

Secret Link