Table of Contents
TL;DR
- Most WordPress backup advice assumes you will read it before you need it. Reality is the opposite — the reading happens after the failure. The post answers the questions you wish you had asked first.
- A real WordPress backup contains four pieces. The wp-content folder. The wp-config.php file. The full database. The URL rewriting rules. Anything less is a partial copy that fights you on the day of the restore.
- Three backup methods cover most small sites. The host’s automated backup. A free backup plugin writing to an off-site cloud account. A monthly manual download. The smallest reliable setup uses two of the three.
- A backup that has never been restored is a hope, not a plan. The fix is a fifteen-minute quarterly drill in a free local WordPress environment. The drill turns a file into a system.
- AI helps with reading. Paste a backup-plugin error into an AI chat and you get a plain-English summary in a minute. AI cannot run the restore for you. You keep the verdict.
Most WordPress backup advice assumes you will read it before you need it. You will read it after.
The Saturday-morning version of the question is honest. The site does not load. The dashboard does not load.
The host email mentions a database error from yesterday. The owner opens a search and types "how to restore WordPress backup." Three articles read in nine minutes. The backup that was set up two years ago has not run for six months because the plugin’s connection to the cloud expired.
The reading is the same reading. The mood is different.
This piece is the calm version of the same questions, asked while the site is still up. Not "back up your WordPress site" as a checkbox. Backup as a system that actually works on the morning a real failure arrives.
Three methods. One quarterly drill. One short list of what should live where.
Why is backing up WordPress harder than it sounds?
A WordPress backup feels like a single thing on the surface. Underneath, the site is two things at once.
Files. The theme, the plugins, the uploaded images, the WordPress core, the wp-config.php that holds the database credentials. The files live on the server’s disk and look like an ordinary folder tree.
A database. The posts, the pages, the comments, the user accounts, the plugin options, the menus, the widgets, every setting that is not a file. The database lives in a separate place on the same server, usually MySQL or MariaDB, accessed by a user account that only WordPress knows about.
A backup of the files alone restores a brand-new empty site with the design but no posts. A backup of the database alone restores a list of posts that have no pages to render them on. Neither half is a real backup. The first job is to remember the site is two things, and any real backup carries both.
The reason this matters: a lot of free backup tools default to one or the other. The "site backup" you see advertised is sometimes a database export. The "files-only" copy a host offers is sometimes the file tree without the database. Read what you are getting before you trust it.
What does a real WordPress backup actually contain?
Four pieces.
The wp-content folder. Themes, plugins, uploads. Everything custom about the site lives here. A backup that misses wp-content is not a backup of the site — it is a backup of WordPress with no site.
The wp-config.php file. The database credentials, the secret keys, the runtime configuration that ties the WordPress files to the database. Without wp-config.php the restored files cannot find the restored database. Two halves do not become a whole until the bridge is in place.
The full WordPress database. The posts, the pages, the options, the users, the comments. Exported as a SQL file.
The size scales with the content of the site, not with the size of the WordPress installation. A small brochure site has a small database. A busy blog has a big one.
The .htaccess or nginx configuration that controls URL rewriting. WordPress permalinks rely on it. Without the rewriting rules the restored site renders posts that 404 when clicked.
The four together can rebuild the site on a fresh server with no other input. Anything missing turns the restore into a guessing game in the wrong week.
Which three backup methods cover most small sites?
Three methods cover almost every small WordPress site.
The host’s automated backup. Most managed WordPress plans include a daily backup with a thirty-day retention window and a self-serve restore button. Many shared-hosting plans include a less reliable version of the same.
Check the cPanel, the host dashboard, or the welcome email before paying for anything else. The host already running a backup is the foundation. The question is whether you trust it alone.
A free backup plugin writing to an off-site cloud account. UpdraftPlus, BackWPup, or Duplicator are the long-running names. The wordpress.org plugin directory carries others.
The plugin runs inside the WordPress site itself and writes the backup to a remote storage account. Pick storage that lives outside the host: Google Drive, Dropbox, Amazon S3, or one of the smaller paid object-storage services. Avoid writing the backup back to the same server’s disk — same-disk backups disappear with the site.
A monthly manual download via the host’s file manager and the database export tool. Old-school. Tedious.
Reliable. Five minutes once a month is a real safety net for the brochure site that almost never changes. The manual copy lives on a laptop or a USB drive, well away from any server.
The three are not exclusive. The smallest reliable setup uses two of the three so a single failure does not leave the site without a copy. The cloud account expires.
The host’s automated backup catches the gap. The plugin breaks. The manual copy is still there.
How often should you back up, and how long should you keep the copies?
Match the schedule to the change rate of the site.
A blog that posts twice a month needs a weekly backup. A small WooCommerce store with daily orders needs a daily backup — a lost order is a lost customer. A brochure site that has not changed in six months needs a backup before every plugin or theme update and one quiet monthly snapshot otherwise.
Retention follows the same logic. Thirty days of daily backups for the active site, ninety days of weekly backups for the slower one. The right retention window is the longest stretch in which a problem could be discovered without anyone noticing the day it happened.
A site quietly compromised six weeks ago needs a backup from seven weeks ago to recover. A thirty-day window is too short for that case.
A useful rule for the WooCommerce store. Keep seven days of daily backups. Add one weekly backup for the past four weeks. Add one monthly backup for the past three months.
The pattern is more copies of the recent past, fewer copies of the older past. Most backup plugins call this a rotation. Most ship sane defaults. The choice is mostly to leave them alone.
Where should the backup live so it survives the failure that broke the site?
Off the same server.
A backup that lives on the same disk as the site is not a backup. It is a copy that disappears with the site when the disk fails or the host account is compromised. The 2024-2025 wave of supply-chain attacks gave a hard answer to a soft question. Attackers who get into the host account also get the backup folder if the backup folder lives on the host.
Off-site means a different account, a different network, a different physical building. Google Drive or Dropbox under a different login than the WordPress admin email. A compromised admin account does not also surrender the backup.
An Amazon S3 bucket whose credentials the WordPress site does not know. The backup writes one-way. The WordPress site cannot delete what it has already written. A second cloud provider, used only for backups, with a password that nobody types into the WordPress admin.
A USB drive in a desk drawer is also off-site. The brochure site that takes one manual snapshot a month is well-served by a labeled USB drive. Old-school is fine for the small site whose recovery story is "the same person who took the snapshot will run the restore."
The shape of the rule is simple. The backup needs to survive the failure that broke the site. If the failure can reach the backup, the backup did not survive.
The host outage. The compromised admin. The disk failure.
The accidental "delete this folder" by the same admin clicking through the file manager. Each one rules out a class of same-server backup. None of them rule out the off-site copy.
How do you test that the backup actually restores?
A backup that has never been restored is a hope, not a plan.
The test is a fifteen-minute quarterly drill. Spin up a free local WordPress environment on a laptop using LocalWP or DevKinsta or Lando. Download the most recent backup. Restore it into the local environment.
Open the home page. Log into the admin. Click around. If the restored copy renders, the backup is real.
The drill catches failures the live site never reveals. The plugin connection to the cloud account expired and nothing was saved for the last two months. The database export skipped a table. The wp-config.php in the backup names a database the host no longer has.
The restore script trips on a permissions issue. None of these show up until the restore runs. The drill makes them show up on a slow Saturday afternoon instead of a fast Saturday morning.
The drill is also the place to test the AI-assisted backup verification plan, which adds a structured checklist on top of the basic restore. The checklist is not the test — the restore is the test. The checklist is the system around the test.
The drill is the smallest discipline that converts a backup file into a backup system.
What can AI help with during backup and recovery?
AI helps with reading and translating, not with the backup itself.
Paste a backup-plugin error message into an AI chat. Claude or ChatGPT or Gemini returns a plain-English summary plus the likely cause in under a minute. The cryptic "could not write to remote storage: HTTP 401" turns into a single line.
"The cloud account credentials have expired. Reconnect the plugin to the storage."
The cryptic "MySQL ERROR 2006" turns into another single line. "The database server timed out during the export. The database is too big to export in one piece without raising the timeout."
Paste a host’s "your backup failed" notification email. The AI tool extracts the line that names the actual file or the actual database table that failed. The owner does not have to read three pages of generic boilerplate to find the one sentence that matters.
Paste the contents of a backup plugin’s settings screen, exported as text. Ask the AI tool whether the schedule, retention, and storage destination match the site’s needs. The chat returns a short audit.
The owner reads it. The owner decides.
AI fails on the live site. It cannot see the server. It cannot reach the disk where the backup lives. It cannot run the restore for you.
The honest framing is the same as on every WordPress troubleshooting question. The AI tool accelerates the read — you keep the verdict. The longer-form security companion piece, the AI-assisted WordPress security audit, covers the same posture across the rest of the security baseline.
Which backup choice should you set up first?
Open the host dashboard.
Check whether the host already runs an automated backup. Note the schedule. Note the retention.
Note whether the restore is a self-serve button or a support ticket. If the restore needs a support ticket, the practical RTO is "Monday morning when support is staffed." That is too slow for a Saturday-night failure. Build a second layer.
Install one free reputable backup plugin and connect it to a Google Drive account whose login is not the WordPress admin email. Run one manual backup. Download the resulting archive file to your laptop.
Open it on your laptop and confirm the wp-content folder and a SQL file are inside the archive. The first proof of life is the file you can open by hand.
Schedule the drill. Pick a Saturday afternoon next quarter. Block fifteen minutes on the calendar.
The drill is the part that turns the file into a system. Without the drill the file is just a hope.
The first piece of the system is one backup that exists in two places, with one self-test scheduled on the calendar. The rest of the backup decisions — retention windows, alternate storage, custom rotations, paid plans — build on top of that floor.
Other questions worth answering
How big are the archive files for a typical WooCommerce store or blog?
About 500 MB is typical for a brochure installation. A busy WooCommerce store with two years of orders often crosses about 5 GB. The database itself stays small for blogs and grows fastest where orders, comments, or log tables accumulate. Plan storage with about double the current archive size as headroom.
Do encrypted archives matter for a brochure page that holds no customer data?
Encryption matters less for purely public pages with no logins. It matters more once a contact form or newsletter list exists, since the archive carries email addresses and hashed passwords. As of 2026, most reputable tools like UpdraftPlus or BackWPup offer a passphrase option. Turn it on the day a form starts collecting names.
What changes for a multisite network or staging environment?
Multisite networks add two complications. The shared database makes exports larger and the rebuild more delicate. Per the 2026 WordPress security substrate guidance, the off-site copy rule still applies, but retention windows often need to run longer. A staging environment generally does not need its own archive because it is already a clone of production.
Does the Automattic-hosted service need its own archive plan?
Yes, although the platform handles a baseline. WordPress.com manages archive storage and the rebuild button on the host side, with retention windows that vary by tier in 2026. The owner cannot upload an archive made elsewhere without paying for the highest tier. An Automattic-hosted owner should still download a manual content export every quarter for portability.
Which backup gap should you close first?
Have a WordPress site whose backup has never been tested for a real restore? You can contact me here. Tell me the host name and the rough size of the site.
I will read your backup posture and name the one gap most likely to bite you on a Saturday morning. There is no pitch, no upsell, and the conversation is free.