A complete WordPress backup covers two things, and only two things: the database and the site files. Miss either one and you don’t have a backup, you have a fragment. The simplest reliable setup is an automated off-site plugin backup, run alongside a separate portable copy you control, with restores tested on a schedule instead of being assumed to work.
TL;DR:
- A complete WordPress backup must include both the database and site files to ensure full restoration.
- Backups should be made in the correct order: export the database first and capture files second, then restore files before importing the database.
- Automated, off-site backup plugins with incremental backups, remote storage, and reliable restore options are essential for managing multiple sites efficiently.
- Storing at least three copies across different locations following the 3-2-1 rule, with off-site encryption, minimizes risk from hardware failure or security incidents.
- Regular testing of restore processes, including quarterly full drills, catches silent failures and ensures backup reliability for quick recovery.
Table of Contents
- What to back up: database vs files, and the order that matters
- Manual file backup: SFTP, file managers and sync workflows
- Manual database backup: phpMyAdmin, mysqldump and WP-CLI
- Automated backups: plugins, host snapshots and managed services
- Where to store backups: the 3‑2‑1 rule and why on-server isn’t enough
- How often to back up and how long to keep copies
- How to restore a WordPress backup: quick and manual routes
- How do you know a backup will actually work?
- Author perspective: why agencies should own recovery, not inherit it
- How Wpcto handles backups so you don’t have to
- Sources
- FAQ
What to back up: database vs files, and the order that matters
Every WordPress site is really two separate assets bolted together. The database holds the dynamic state: posts, pages, users, orders, comments and settings. The files hold everything static: wp-content (your uploads, plugins and themes), wp-config.php, and the other root files that tell the server how to run the site. Backing up only one of these produces a partial, non-functional site on restore, no matter how recent the copy is.
Uploads deserve particular respect. They’re unique, unrepeatable files, client photography, PDFs, video, that no plugin or theme can regenerate. Lose the uploads folder and you lose client work permanently, even if every plugin and every database row survives intact.
For the backup itself, the order is simple:
- Export the database first, while the site is in its current state.
- Capture the files second, ideally in the same window, to avoid a mismatch between what the database references and what the files actually contain.
- On restore, files typically go back first, then the database imports on top, though a migration involving a new domain changes that sequence slightly (more on that below).
Statistic worth remembering: the two components aren’t optional extras to each other. WordPress’s own developer documentation treats database and files as the two mandatory halves of a “complete” backup, with no partial-credit version.
Manual file backup: SFTP, file managers and sync workflows
For agencies managing more than a handful of sites, manual file backups are usually a fallback rather than daily practice, but every account manager should know how to do one under pressure.
- Connect over SFTP, not plain FTP. SFTP encrypts the credentials and the transfer; plain FTP sends your password in the open. Most hosts provide SFTP details in the same panel as regular FTP.
- Download
wp-contentin full, includinguploads,pluginsandthemes. This is the largest and most important folder on the server. - Grab
wp-config.phpand.htaccessfrom the root. These small files carry database credentials and server rewrite rules, both essential for a working restore. - Skip cache folders and any existing backup-plugin directories. They bloat the archive with files you’ll never need and sometimes contain stale, conflicting copies of the site.
- Compress the result into a dated archive (
sitename_2026-03-14.zip) so you can tell at a glance which copy is which, and keep at least three dated versions rather than overwriting the last one.
For anything beyond a one-off, consider one of the top backup plugins designed for WooCommerce sites, which automate syncing only changed files rather than re-downloading everything each time.
Pro Tip: Name your archives with the date first, not last (2026-03-14_sitename.zip). Sorted alphabetically, that puts your most recent backup at the top of every folder without you having to check timestamps.
Manual database backup: phpMyAdmin, mysqldump and WP-CLI
The database is smaller than the files but far less forgiving of a bad export. A corrupted SQL dump can look fine until the moment you try to import it.
- In phpMyAdmin, select the database, choose “Export,” pick the “Custom” method, and export as SQL. For anything over a few hundred megabytes, compress it as
.gzon export rather than after, since large uncompressed dumps are prone to timing out mid-transfer. - From the command line,
mysqldumpdoes the same job with more control. Add the--single-transactionflag for InnoDB tables, which locks the export to a consistent snapshot rather than capturing a database that’s still being written to mid-export, a real risk on any site taking live orders or comments. wp db exportvia WP-CLI is the cleanest option for automation, since it can be scripted, scheduled with cron, and piped straight into a compression tool without opening a browser at all.
For very large databases (multi-gigabyte WooCommerce sites are the usual culprit), split the export by table, or run it during the lowest-traffic hour you can identify, since a mysqldump without --single-transaction on a busy InnoDB database is one of the more common causes of a backup that looks complete but fails to restore cleanly.
Automated backups: plugins, host snapshots and managed services
Manual exports don’t scale across a client portfolio. This is where most agencies land on some combination of plugin automation and host snapshots, and where most also make the same mistake: trusting one when they need both.
Look for these features when evaluating a backup plugin:
- Incremental backups, which only copy what’s changed since the last run, cutting both server load and storage cost.
- Remote storage destinations built in, so the backup leaves the server automatically rather than sitting in a folder on the same machine.
- One-click restore, tested and reliable, not just theoretically available.
- Activity logs, so you can see at a glance whether last night’s job actually completed.
Tools such as UpdraftPlus and BlogVault are commonly used because they combine incremental backups, remote storage and one-click restore in a single setup, which covers most of an agency’s day-to-day needs without custom scripting.
Host snapshots are convenient, but they’re not the same thing as a real backup strategy. They often have short retention windows and they live on the same infrastructure as the live site. If that host has an outage, a billing lapse, or a security incident, your snapshot goes down with it. WordPress’s own documentation is blunt about this: operators should maintain independent backups even when a host claims to handle it.
Pro Tip: Ask your host directly how long they retain automatic snapshots, and get the answer in writing. “We back you up” often means “for the last three days,” which is not a real safety net.
Where to store backups: the 3‑2‑1 rule and why on-server isn’t enough
The 3‑2‑1 rule translates neatly to WordPress: keep three copies of your data, on two different types of storage, with one copy off-site. In practice, that means the live site is copy one, a local or plugin-generated backup on the server is copy two, and a genuinely separate off-site destination is copy three.
- Amazon S3, with lifecycle rules and object lock enabled, protects against both accidental deletion and ransom-style attacks that try to wipe backups along with the live site.
- Backblaze B2 is a lower-cost alternative for agencies running this across many client sites.
- Google Drive works for smaller sites or lighter budgets, though it lacks the lifecycle and immutability controls of the other two.
Whichever target you choose, separate the credentials for your backup storage from your hosting login, and encrypt backups at rest. Same-server backups fail as a strategy precisely because they share a single point of failure with the site they’re meant to protect.
How often to back up and how long to keep copies
Retention and frequency should follow how much data the site would lose in an outage, not a one-size-fits-all schedule. Different sites require more frequent backups and longer retention depending on their type and activity levels.
Frequency is really about your RPO (recovery point objective, how much data you can afford to lose) and your RTO (recovery time objective, how fast the site needs to be back up). A daily backup accepts up to 24 hours of lost orders or comments; if that’s too much for a client’s ecommerce store, the tooling and cost step up accordingly.
How to restore a WordPress backup: quick and manual routes
Restoring is where a backup either proves its worth or reveals it was never really usable. There are two routes, and every agency should know both.
Quick plugin restore, when the dashboard is reachable:
- Open the backup plugin, select the most recent verified backup (not just the most recent one, check it actually completed).
- Choose to restore both database and files together, unless you have a specific reason to restore only one.
- Let the restore finish fully before making any other changes to the site.
Manual full restore, when the dashboard is inaccessible:
- Take a fresh snapshot of the current broken state first, in case you need to revert your restore attempt.
- Upload the file backup via SFTP, overwriting
wp-contentand the root files. - Import the SQL dump through phpMyAdmin or
wp db importvia WP-CLI. - If you’re migrating to a new domain or server, update
wp-config.phpand the site URL in the database so links and assets resolve correctly.
Pro Tip: Time every restore, even the successful ones. If your RTO target is two hours and a routine restore takes three, you’ve found the gap before a client emergency forces you to find it live.
How do you know a backup will actually work?
A backup nobody has restored is a guess, not a safety net. Regular restore drills catch the silent failures that a green “backup complete” notification never reveals.
- Run a full restore to a staging environment every quarter, checking login, forms and checkout as a minimum.
- Turn on failure notifications for both the plugin and the host, so a missed backup surfaces immediately rather than three months later.
- Keep a written restore runbook and store backup credentials somewhere secure and accessible to more than one person on your team.
Pro Tip: Log how long each quarterly drill takes. A restore that’s getting slower every quarter is telling you the site has outgrown its current backup tooling, before that becomes an emergency.
Author perspective: why agencies should own recovery, not inherit it
The real cost of unmanaged backups isn’t the storage bill, it’s the Sunday evening call when a plugin update breaks a client site and nobody’s tested a restore in months. Agencies that treat backups as infrastructure, not an afterthought, stop firefighting and start billing for it properly.
— Marcel
How Wpcto handles backups so you don’t have to
Running an agency means your team’s time should go into design and strategy, not chasing failed cron jobs or manually checking whether last night’s backup actually completed. A specialist WordPress management service can handle backup schedules, off-site storage, and restore verification to keep your client relationship intact while managing the technical details invisibly.
Our agency maintenance and support services cover backups as a standard part of the SLA, alongside security monitoring, performance work and plugin management, so nothing falls through the cracks between “we updated it” and “we checked it restores.” If you’re not sure how much unmanaged WordPress risk is sitting inside your current client base, run it through our WordPress Profit Calculator, it takes under 90 seconds and shows exactly how much recurring revenue and risk exposure is hiding in the sites you already manage.
For agencies weighing up white-label delivery, our white label WordPress support option lets you offer backup and maintenance cover under your own brand without building the capability in-house. Whichever route fits your agency, the next step is the same: run the calculator and see where the gaps actually are before your next client incident finds them for you.
Sources
FAQ
How do I back up my entire WordPress site?
Export the database (via phpMyAdmin, mysqldump or WP-CLI) and download the files (wp-content, wp-config.php, .htaccess) via SFTP, then store both copies off-site, ideally through an automated plugin or managed backup service.
How can I manually back up my WordPress site?
Use phpMyAdmin or mysqldump --single-transaction for the database, then SFTP into the server to download wp-content and the root configuration files, compressing both into dated archives.
How can I back up my WordPress website for free?
WordPress’s own export tools and open-source plugins cover most sites at no cost, though free tiers often cap storage or skip remote destinations, which matters most for larger ecommerce sites.
How can I back up my WordPress site locally?
Download the database export and the wp-content folder via SFTP to a folder on your own machine, but treat this as a temporary or supplementary copy rather than your primary backup, since local storage doesn’t meet the off-site requirement of the 3‑2‑1 rule.
How do I restore a WordPress backup?
Most plugins offer a one-click restore for both database and files together; if the dashboard is inaccessible, upload files via SFTP and import the SQL dump through phpMyAdmin or WP-CLI manually, as outlined in our restore guide.