A Complete Guide to WordPress Backup

What is a WordPress backup?

A WordPress backup is a saved copy of everything your site needs to run. That covers the files on your server and the database that sits behind them. If either half goes missing, you do not have a recoverable site.

The WordPress.org Advanced Administration Handbook draws a clean distinction worth holding onto. Your WordPress files live in your site’s directory on the web server. That includes the core application, themes, plugins, media uploads, and configuration files like wp-config.php and .htaccess. Your database lives somewhere else entirely, usually a MySQL or MariaDB instance that stores posts, pages, comments, user accounts, plugin settings, widget configurations, and WooCommerce orders. Backing up the directory does not back up the database. Backing up the database does not back up the files.

A usable backup captures both, ideally created around the same time, so the two halves stay in sync. The WordPress handbook calls this a “backup set”, meaning files and database are treated as one unit, restored together, and kept paired as versions.

The article on types of WordPress backups goes deeper into full versus incremental versus differential backups, which change how the copy gets made rather than what it includes. Before getting into strategy, it is worth being clear that a complete backup means both database and directory, captured together, stored somewhere you can get to them when your site is down.

Why are regular WordPress backups important?

The case for backups used to be mostly theoretical for smaller sites. That has changed. Patchstack’s State of WordPress Security In 2026 report, published with malware intelligence firm Monarx in February 2026, documented 11,334 new WordPress vulnerabilities in 2025. That represents a 42% increase over the previous year. More high-severity vulnerabilities surfaced in 2025 than in the previous two years combined. Plugins accounted for 91% of those issues, with only six vulnerabilities found in WordPress core.

The speed problem is worse than the volume. Patchstack’s data shows 20% of exploited vulnerabilities are hit within six hours of public disclosure, 45% within 24 hours, and 70% within a week. The weighted median time to first exploitation sits at five hours. Plugin updates have always functioned as a second line of defense. A defense that takes a day to deploy against attacks that arrive within hours is not a defense most agencies can rely on.

Backups do not replace security. They are the recovery mechanism when security fails, and the 2025 data says security is failing often enough that the recovery mechanism has to work. A site that has been compromised or injected with malware needs to be rolled back to a clean state from before the compromise. Without a pre-attack backup, the alternative is manually cleaning infected files, an exercise that takes agencies hours to days per site and rarely produces the confidence a clean restore does.

For agencies managing dozens or hundreds of client sites, the math compounds quickly. One broken site is a billable emergency. Ten broken sites, a crisis. Backups are what keep a crisis from becoming a liability conversation.

What does a complete WordPress backup include?

WordPress backup covers three main things: files, database, and server-level settings.

Backup files cover your WordPress core installation, active and inactive themes, all installed plugins, the entire wp-content/uploads directory (every image, PDF, and media file your site has ever served), and root-level configuration files. Important configuration files include wp-config.php (which holds database credentials and security keys), .htaccess (which controls URL rewrites and access rules on Apache servers), and in some setups php.ini or user.ini for PHP configuration overrides.

The database includes almost everything that feels like “content” from an editorial perspective, such as posts, pages, custom post types, categories, tags, menus, widgets stored as options, comments, user accounts and roles, theme customizer settings, plugin settings, and every row of transactional data from plugins like WooCommerce, Easy Digital Downloads, or any membership tool you are running.

Server-level configurations include things like cron jobs set at the server level rather than through WordPress, custom mail server settings, and SSL certificate files managed outside your host’s dashboard, which are not inside your WordPress install. Neither are DNS records, domain registrar settings, or third-party integrations whose credentials might live in a plugin’s database table but whose external state (webhooks registered, API connections authorized) has to be re-established manually after a restore to a new environment.

For most restores to the same server, the last category never comes up. For migrations to a new host, or full disaster recovery from a completely lost server, it’s an occasional thing.

A genuinely complete backup strategy, then, covers both halves of the WordPress install plus a documented inventory of what lives outside it. Your plugin or platform handles the first two pieces. You handle the third.

Types of WordPress backups

WordPress backups fall into a few useful categories that shape how you set things up.

1. By scope, backups can be full, incremental, or differential. A full backup captures every file and every database table in one archive. An incremental backup only captures what has changed since the last backup of any type, which saves storage and bandwidth on sites that change frequently. A differential backup captures everything that changed since the last full backup. Each has trade-offs around storage, restore complexity, and how long a restore takes. Read more about the differences between full, incremental, and differential backups.
2. By method, backups can be manual or automated. Manual means you run the backup yourself using cPanel, FTP, WP-CLI, or phpMyAdmin. Automated means a plugin or hosting provider runs backups on a schedule. For anything beyond a personal blog, automated backups are the practical default.
3. By location, backups can sit on your server or off-site. On-server backups are fast to create and fast to restore. They are also useless if the entire server is compromised. That is why offsite backups are not optional.

How often should you back up your WordPress site?

How often you back up depends on how much content your site loses between backups. A site that publishes one post a week and a WooCommerce store processing fifty orders a day sit at completely different ends of this question. Match the schedule to what your site changes. A few common WordPress site profiles and what usually works:

• Static brochure sites or portfolios that update a few times a month: daily incremental backups. The overhead is negligible, and it covers you against the surprise edit or plugin update that happens outside your usual rhythm.
• Content sites, blogs, and business sites publishing regularly: daily incremental backups cover almost every realistic scenario.
• WooCommerce stores processing orders throughout the day: hourly backups at a minimum. Every hour without a backup is an hour of orders, customer accounts, and inventory changes that cannot be reconstructed if the database is lost.
• Membership sites and LMS platforms with active user submissions, course progress, or forum activity: hourly backups for the same reason. Users creating accounts, completing lessons, or posting in forums expect their activity to persist.
• High-traffic publications or news sites: hourly backups, with close attention to the uploads folder since media additions are frequent and often substantial in size.

Retention matters as much as frequency. Keeping only the last two or three backups feels clean, but it collapses your options if a problem has been silently present for longer than that window. Malware that sits undetected for a week, a database corruption that took days to manifest, or a regression from a plugin update that went unnoticed for ten days all require backups older than a short retention window. Thirty days is a sensible floor for agency-managed sites, and fifty days covers almost every realistic detection window.

How to back up a WordPress website

You can back up a WordPress website in four ways: with a backup plugin, through your hosting provider, manually via WP-CLI or phpMyAdmin, or through a WordPress management platform. Which one fits depends on how many sites you manage and how much of the work you want to automate.

WordPress backup plugins like UpdraftPlus, BlogVault, and Duplicator install directly on the site and handle backups from inside the wp-admin. They work well for solo site owners and small operations. They are cheap or free, easy to set up, and bundle restore workflows into the same interface.

Hosting provider backups are bundled with most managed WordPress hosts. They are convenient and often stored outside your immediate server environment. They work as one layer of a backup strategy, rarely as the only layer.

Manual backups via WP-CLI, cPanel, or phpMyAdmin give developers full control and avoid adding another plugin to the stack. They are also time-consuming to run on a regular schedule across multiple sites and do not scale past a handful of installs for most teams.

WordPress management platforms like WP Umbrella, ManageWP, and MainWP handle backups as one feature among many, running them centrally from a dashboard that manages all your sites. For agencies and anyone managing more than three or four sites, this is usually the right level of tooling. Backups happen alongside updates, monitoring, and security scanning, and restore workflows work the same across every site in the account.

Also read: How to Back Up Your WordPress Site (Without Losing Your Mind)

For a detailed comparison of the leading backup plugins and platforms, including feature breakdowns and pricing, see the 8 best WordPress backup plugins. 

How to set up WordPress backups

Setting up WordPress backups follows the same shape regardless of which tool you pick. The specifics vary, but the workflow is consistent.

1. Decide what you are backing up. Default to files plus database backups unless you have a specific reason to split them.

2. Choose a frequency based on your site profiles.

3. Set up off-site storage. Connect the backup tool to Amazon S3, Google Drive, Dropbox, or a similar destination. Or, if a WordPress backup tool stores backups on its own infrastructure, confirm where those servers live and whether that works for your compliance needs.

4. Configure retention. Thirty days as a minimum. Longer if you are handling sites where problems might go unnoticed for weeks.

5. Make sure failed backups trigger emails or Slack alerts immediately.

6. Create a staging site, restore the latest backup to it, and confirm everything works. If you cannot restore the backup, the backup does not exist for practical purposes.

Related: WordPress Backup and Restore: A Complete Guide for Agencies Managing Client Sites.

Testing and restoring WordPress backups

A backup you have never restored is a wish, not a backup. Agencies that have been through a real restore emergency tend to share one instinct: they test restores before they need them.

Testing a backup restore on a live site is risky, so do it on a staging environment instead. Most managed WordPress hosts provide one-click staging. Restore your latest backup to that staging site, then walk through the homepage, key internal pages, admin dashboard, WooCommerce checkout if applicable, and critical plugin functions like forms and payment processors. If any of those fail, the backup itself or the restore workflow has a problem, and finding that out during a scheduled test is a lot cheaper than finding out during an actual outage.

How often to test depends on how critical the site is. A quarterly restore test is the minimum for agency-managed sites. Business-critical sites like ecommerce, membership, and transactional platforms deserve monthly tests. Document each test, including whether the restore completed, how long it took, and whether any pieces were missing or broken.

Advanced WordPress backup strategies

Beyond the baseline, a few patterns are worth considering for larger or more complex sites.

Incremental backups for large sites. When your uploads directory crosses a few gigabytes, full backups every day become slow and expensive. Incremental backups capture only what has changed since the last backup, which keeps storage and transfer costs manageable. Most modern backup tools support incremental as an option on top of scheduled fulls. The trade-off is slightly more complex restores, because the restore has to chain the last full backup plus every incremental on top of it.

Backup-before-update as a standing rule. The single most common cause of needing a backup restore is a bad update, whether that is WordPress core, a theme, or (most often) a plugin. Taking a backup immediately before any update, rather than trusting the scheduled backup from earlier, means the restore point is exactly at the known-good state.

Safe Update patterns. A disciplined update workflow looks like this: create an on-demand restore point, apply the update, run automated checks (does the homepage still load, does the admin still work, do key functions still respond), and either keep the update or roll back based on the result. Manual versions of this workflow are possible. Automated versions are faster and more reliable, especially across multiple sites.

Multisite considerations. WordPress multisite networks complicate backups in a few ways. Uploads live in a per-site folder structure, the database stores site content in per-site tables, and restoring a single site from a network-wide backup is not trivial without the right tooling. If you run multisite, confirm your backup tool supports network-wide backup with per-site restore, not just a monolithic network restore.

Also read: WordPress Multisite vs. Separate Installs: What Agencies Should Choose?

Pre-deploy backup automation. For teams running CI/CD against WordPress sites, tie a backup trigger into the deploy pipeline. Every deploy generates a restore point. That way, even deploys that pass all tests have a guaranteed rollback option if something surfaces in production that staging missed.

Common WordPress backup mistakes to avoid

Relying on host backups as your only line of defense. Hosting backups are convenient, and the worst time to learn their limitations is during an outage. Common limitations include short retention windows, slow restore times that require support tickets, storage in the same environment as the production site, and opacity around what is being backed up. Use host backups as one layer. Never as the only layer.

Backups that have never been restored. A backup file can be corrupted, incomplete, or broken in ways that only show up at restore time. If you have not tested a restore, you do not know whether your backups work. Quarterly at minimum, monthly for critical sites.

Partial backups treated as complete. Database-only backups miss your uploads, theme modifications, and plugin files. Files-only backups miss all your content. Both are equally important. If the tool lets you configure partial backups, double-check what is being captured before assuming you have coverage.

Backups stored on the same server as the site. If a ransomware attack, server compromise, or account suspension takes out the live site, backups in the same environment go with it. This is the single most important principle in the 3-2-1 rule, and it is the one most frequently violated.

Stale retention policies. A 7-day retention window is not long enough to recover from a problem that took 10 days to notice. Malware, database corruption, and regressions introduced by plugin updates often sit undetected for longer than a week. Default to 30 days minimum.

Treating “downloaded to my laptop” as a backup strategy. One-off local copies are fine as a supplement. They are not a substitute for systematic, scheduled, off-site backup storage. Laptops get lost, stolen, wiped, or simply forgotten.

Ignoring WooCommerce-specific concerns. E-commerce sites generate transactional data like orders, customer records, and inventory changes between backups. A 24-hour gap between backups on a store that processes 50 orders a day is 50 orders you might have to reconstruct manually. Back up WooCommerce databases more frequently than their content-site equivalents.

How backups fit into WordPress maintenance

Backups work best as one layer of a broader maintenance approach, rather than a standalone insurance policy you hope never to use.

A mature WordPress maintenance practice covers a handful of interlocking responsibilities. Updates keep WordPress core, plugins, and themes current, which closes off known vulnerabilities. Security monitoring and vulnerability scanning catch problems before they become exploits. Uptime monitoring tells you when a site goes down, and performance monitoring tells you when it is about to. Backups are the safety net that makes every other layer safer to operate, because knowing you can roll back cleanly means you can update more confidently and investigate issues more aggressively.

The relationship between backups and updates is particularly close. Most restore emergencies happen after a botched update. Running an update without a current backup is the WordPress equivalent of rock climbing without a rope. It works fine until it does not, and the consequences are much worse than the cost of being careful.

The relationship between backups and security is similar. When a site is compromised, the recovery path almost always involves restoring from a pre-compromise backup, not trying to clean the infection in place. Security tools catch the compromise. Backups give you a way out.

WP Umbrella handles WordPress backups as part of complete site maintenance

Running backups on a single site is manageable with almost any tool. Running reliable, tested, off-site backups across dozens of client sites while also staying on top of updates, security, performance, and reporting is a different problem. That is the problem WP Umbrella is built for.

WP Umbrella’s backup feature includes daily, weekly, and monthly automated backup schedules, with hourly backups available as an add-on for WooCommerce and other high-frequency sites. Backups are incremental, encrypted, and stored in the EU for GDPR compliance.

Retention runs for 50 days by default, which covers most scenarios where a problem has been silently present for longer than a rolling window would catch. Restore options include one-click full site restores, selective restores of files or database only, and single-folder restores down to the plugin level, which matters when you need to roll back a specific change without undoing everything else.

Alongside backups, WP Umbrella handles the rest of the maintenance stack from the same dashboard.

Uptime and performance monitoring runs multi-location checks from servers in Europe, Asia, Australia, and the US, with configurable intervals from 2 minutes to 1 hour. Time to First Byte tracking, Google PageSpeed monitoring, and PHP error visibility at the site level all live in the same dashboard. SSL and domain expiry monitoring catch the kinds of quiet failures that otherwise take clients by surprise. Alerts route through email or Slack.

Plugin and theme updates run through Safe Update modes (Quick, Classic Safe, and Advanced Safe) that create a backup snapshot before applying updates, giving you a guaranteed restore point if anything goes wrong. Bulk core, plugin, and theme update workflows handle changes across an entire portfolio in one operation. Plugin History keeps a record of every change made to every plugin across every site, turning “when did this break” into a question with an actual answer.

Vulnerability and security monitoring runs continuous scans every 6 hours using Patchstack’s vulnerability database, surfacing issues through a per-site risk dashboard. For sites that need protection before patches are available, the Site Protect add-on provides Patchstack-powered virtual patching at €2 per site per month, which closes the window between disclosure and update that leaves most sites exposed.

White-label client reporting pulls all of this together into automated weekly, monthly, or quarterly reports with your agency’s branding, showing clients the maintenance work they are paying for in a way they actually read.

For agencies, freelancers, and anyone managing WordPress sites at scale, consolidating backups into a maintenance workflow rather than running them as an isolated tool changes what the day-to-day operations look like. Instead of managing seven different logins and hoping each of them is running correctly, you get one dashboard where backups, updates, security, and monitoring all live in the same place.

Start your free WP Umbrella trial and bring your client sites under one roof.