WordPress Backups: What Most People Get Wrong

A backup you have never restored is a hypothesis.

That is the whole article in a sentence, and it is where most backup strategies fail — not at taking backups, which is easy and automated, but at the assumption that what was taken can be turned back into a working site.

Four other things go wrong routinely, and all five are fixable in an afternoon.

---

Mistake 1 — Never testing a restore

Backups fail silently. A schedule that has been running for two years can be producing files that will not restore, and nothing tells you until the day it matters.

Common silent failures:

• The database dump is incomplete because it timed out on a large table
• Files were skipped for permissions reasons and the log went unread
• The archive is corrupt
• The destination filled up months ago and new backups stopped
• The plugin was deactivated during a troubleshooting session and never reactivated

The drill, once:

1. Create a staging site, or a local install
2. Restore your most recent backup to it
3. Check the front end, the admin, a form, and — if you sell — a checkout
4. Note how long it took and what you needed

Two things come out of it. You learn whether the backup works, and you learn the restore procedure while nothing is on fire. Both matter, and the second is underrated — the first time you restore should not be during an outage.

Repeat quarterly. It takes twenty minutes once you have done it.

---

Mistake 2 — Backing up only files, or only the database

Neither restores a site alone, and this catches people out because both feel complete.

Component	Holds	Without it
Database	Posts, pages, settings, users, comments	A working theme with no content
Files	Themes, plugins, uploads, wp-config.php	Content with nothing to render it

Both. Every time.

What must be included:

• wp-content in full — themes, plugins, uploads
• wp-config.php
• .htaccess
• The complete database

What can be excluded: WordPress core, which is downloadable from wordpress.org, and cache directories, which are regenerated. Excluding those meaningfully reduces backup size on most sites.

---

Mistake 3 — Storing backups on the same server

A backup on the machine you are backing up protects against exactly one scenario: you broke something and the server is fine.

It does not survive server failure, host account suspension, ransomware, or a compromise — an attacker who reaches your server reaches your backups, and deleting them is a standard step.

Store off-server. Cloud storage, a different host, or a local copy pulled down on a schedule.

A workable version of the 3-2-1 principle: three copies, on two kinds of storage, one off-site. For a small site that is usually the live site, an automated cloud copy, and an occasional manual download.

---

Mistake 4 — Retaining too little history

A compromise or a corruption is often discovered weeks after it happened, and by then a seven-day retention window contains only compromised copies.

Workable retention:

• Daily backups, kept for a fortnight
• Weekly backups, kept for two months
• Monthly backups, kept for a year

Storage is cheap relative to the alternative, and this schedule keeps the total modest by thinning older copies rather than keeping everything.

Take an extra backup before anything risky — updates, migrations, theme changes, plugin installs. Most backup plugins can trigger on update automatically.

---

Mistake 5 — Assuming the host's backups are enough

They frequently are not, and the reasons are worth checking rather than assuming.

Ask your host four questions:

• How far back do they go? Often seven days, which is not enough for a late-discovered problem
• Can you restore yourself, or must you raise a ticket? A ticket during an outage is a delay you do not control
• Can you restore selectively — files only, database only, one file — or is it all-or-nothing?
• Can you download a copy? A backup you cannot take with you is not portable to a new host

Host backups are a good safety net and a poor primary strategy. Run your own alongside, and know which you would reach for.

---

A working setup

For a small site:

1. A backup plugin taking files and database
2. Daily automatic, or matching your publishing frequency
3. Stored in cloud storage, off-server
4. Retention of two weeks daily, two months weekly, one year monthly
5. An extra backup before updates, triggered automatically
6. Email confirmation on failure, not on success — success notifications get filtered and stop being read
7. A quarterly restore test to staging

That last item is the one that turns the rest into an actual strategy.

---

Restoring properly

Two things to decide before you restore anything.

Files, database, or both? If the problem is a broken plugin update, restoring wp-content alone fixes it without reverting content. Restoring everything to fix a code problem loses every post published since the backup, and it is the most common self-inflicted loss during a recovery.

What has changed since the backup? Note recent posts, orders, comments and user registrations before restoring. Ten minutes of checking prevents losing a week of work.

One critical exception: after a compromise. Restoring reverts the visible damage and reinstalls the vulnerability that let them in, and the backup may already contain the backdoor. Restoring is part of that recovery and never the first step. The triage order.

---

Frequently asked questions

How often should I back up?
Match it to how much work you are willing to lose. Daily suits most sites; a store taking orders should back up more often, and a site publishing monthly can do less. Take an extra backup before any update or migration.

Is my host's backup enough?
Usually not as a primary strategy. Check how far back they go, whether you can restore without raising a ticket, whether restores are selective or all-or-nothing, and whether you can download a copy. Host backups make a good safety net alongside your own.

Where should backups be stored?
Off the server being backed up. A backup on the same machine does not survive server failure, account suspension, or a compromise — an attacker who reaches your server reaches your backups, and deleting them is a standard step.

How do I restore a WordPress backup?
Through your backup plugin's restore function, or manually by uploading files and importing the database dump. Decide first whether you need files, database or both — restoring everything to fix a code problem reverts all content published since the backup.

What should a backup include?
The full wp-content directory, wp-config.php, .htaccess, and the complete database. WordPress core can be excluded since it is downloadable, and cache directories can be excluded since they regenerate.

Should I restore from backup after being hacked?
Not as a first step. Restoring reverts visible damage and reinstalls the vulnerability, and if the intrusion predates your discovery the backup may already contain the backdoor. Find the entry point first, then restore or rebuild as part of a full clean.