WordPress Backups Explained

Updated 26 September 2026 · 5 min read

A WordPress site is two halves: files on disk and content in a database. If you copy only one half, you cannot put the site back. Backups exist so that a bad update, a deleted page, a failed plugin, or a compromised file is annoying instead of final. This guide covers files versus database, frequency, off-site storage, host backups versus plugin backups, test restores, and a simple routine you can actually keep. UpdraftPlus is named only as a familiar example of a backup plugin, not as a recommendation over others.

Files versus database

The database (usually MySQL or MariaDB) holds posts, pages, comments, users, plugin settings, and most of what you edit in wp-admin. If you lose it, you lose the words. The files include WordPress core, themes, plugins, and wp-content/uploads (images, PDFs, the media library). If you lose uploads, you keep the posts but every image breaks.

A complete backup has both. Some tools also export a list of active plugins. That is helpful but not a substitute for the folders themselves, especially for custom plugins that do not live in the directory.

What you can often skip in a backup copy: cache folders that plugins can rebuild, and node_modules if you somehow deployed those (you usually should not). When in doubt, include wp-content whole. Core files can be downloaded again from WordPress.org, but restoring a matching full copy is simpler in an emergency.

wp-config.php holds database secrets. Store backups privately. A public “backup.zip” in the web root is a gift to attackers. That risk is why backups belong in the plugin security checklist as well as in operations.

How often is enough

Match frequency to how fast the site changes and how much work you would be willing to redo.

A brochure site that changes monthly can live with weekly backups plus an extra copy before any update.
A blog that publishes often, or a shop with orders, needs daily database copies at least, and files as often as uploads change.
Before every bulk plugin update, theme switch, or migration: one extra backup, on purpose, with a name you can find.

Retention matters as much as frequency. If you keep only one copy and it runs after a compromise, you have a backup of the infected site. Keep several dated copies (for example, daily for a week and weekly for a month). Exact schedules depend on disk cost and how busy the site is; the principle is that you can rewind to before the bad day.

Off-site storage

A backup that lives only on the same server dies with the server. Off-site means another company’s storage, a different account, or at least a download you copy to a machine that is not the web host. Encrypted or access-controlled is better than a world-readable bucket.

Name files with the site and the date. Confirm that scheduled copies actually appear. Silent failure is common: an API key expired, the disk filled, the cron job never ran. A monthly glance at the destination folder is part of the backup.

Do not email yourself full site zips as the only copy. Mail systems reject large files, and inboxes are not a vault. Do not store backups inside wp-content/uploads on a public URL.

Host backups versus plugin backups

Hosts often snapshot the whole account: files, database, sometimes email. Strengths: complete, independent of WordPress crashing, easy to roll back the entire account. Weaknesses: you may not control the hour, restores can take a support ticket, and you might not be able to grab a single page. Some host backups skip parts of the account or overwrite on a short rotation.

Plugin backups run inside WordPress (or via WP-CLI on some stacks). Strengths: you can schedule, send copies off-site, and restore into a staging site. Weaknesses: if PHP is on fire, the plugin cannot run; a compromised site can also compromise the plugin’s stored credentials if you are unlucky. UpdraftPlus-style plugins typically let you pick files, database, and a remote destination. Other plugins do the same job with different screens. One such plugin is enough.

The durable pattern is both: host snapshots as the floor, plus a plugin or other off-site copy you control. They should not fight. Exclude backup archives from other backup archives so you do not nest copies forever.

Test restores

An untested backup is a hope. At least once, restore onto staging or a local copy:

Create an empty site or staging slot.
Restore files and import the database according to the tool’s docs.
Update wp-config.php if the database name or host differs.
Search-replace the site URL if the restore is on a different domain (use a purpose-built method so serialized data does not break).
Log in, check a few pages, a form, and the media library.

Note how long it took and where you got stuck. That note is the runbook for a bad morning. If restore requires a developer, write that down too so you do not discover it during an outage.

Partial restores matter. Can you recover one deleted page from yesterday without rolling the whole shop back? Some tools allow a database-only restore; others do not. Knowing the answer changes how brave you are when editing.

A simple backup routine

For a typical small business site:

Confirm the host’s snapshot exists and how to request a restore.
Install one backup plugin (or use a host-provided scheduled copy to off-site storage).
Include database + wp-content at minimum.
Send copies off-site on a schedule that matches how often you publish.
Keep multiple dates.
Before plugin or theme updates, click an extra backup. This pairs with how to choose a WordPress plugin and with performance experiments in caching and performance plugins explained.
Once a quarter, restore to staging and tick a box on a calendar.
Once a quarter, delete leftover backup zips from the public web root if a plugin left any there.

Write the steps in a document someone else could follow, including where the credentials live. A backup only you understand is a single point of failure.

When a backup is not enough

Backups do not replace updates, 2FA, or avoiding nulled plugins. They also do not replace working copies of legal documents or customer records you are required to keep elsewhere. If you sell downloads, know whether those files sit in uploads or on another service.

If a restore would lose a day’s orders, look at more frequent database dumps during business hours, or a host plan that supports them. Do not pretend a weekly file zip covers a busy cart.

Checklist

Both database and files (especially uploads), stored privately.
A copy off the web server, with several dates retained.
Host snapshot plus one controlled off-site method, not three overlapping plugins.
Extra backup before updates and migrations.
A restore you have actually performed on staging.
No backup zips sitting at public URLs.

Schedule the quarterly restore test the same day you review plugins. Recoverability is a feature of the site, as much as the theme is.

Related guides

Independent information; we are not affiliated with WordPress or any plugin developer. Always back up before changing plugins.