Every site owner says they have a backup. Few have restored one. The difference shows up at the worst possible moment: after a hack, a broken plugin or a dropped table. A backup you never test is not a backup; it is a hope.
What you must back up
- Site files: themes, plugins and uploads.
- The database: posts, pages, settings and users. This is the part that hurts to lose.
- Config files: wp-config.php and any mail settings.
Files alone are not enough. You can restore a full site and find it empty without the database.
Three ways to do it
- A backup plugin: easiest for beginners. Schedule daily and push to remote storage.
- Manual export: dump the database and zip the site folder before any major update.
- Host-level snapshots: some panels provide full backups. Check the frequency and retention.
Golden rule: keep a copy where your site does not live. If the server dies, a backup on the same server dies with it.
A realistic schedule
| Site type | Frequency | Retention |
|---|---|---|
| Personal blog | Weekly | 4 copies |
| Business site | Daily | 14 copies |
| Store or signup platform | Twice daily | 30 copies |
Also back up before every plugin or theme update; do not rely on the schedule alone.
Test the restore
Once a quarter, restore to a staging domain or subfolder and check three things: the site loads, images appear, and you can log in to wp-admin. If any fails, your plan needs fixing now, not on the day you need it.
Silent backup failures
- A backup with no database at all.
- A corrupt archive from a dropped upload.
- Wrong file permissions after restore, producing 500 errors.
- A stale copy that has not run in months without an alert.
Backups are only half of safety. Read securing WordPress to reduce the chance you ever need a restore, and if you are changing hosts, follow migrating WordPress first.
The first ten minutes after a hack
Do not try to fix everything at once. Change passwords from a clean device, disable plugins and themes, and review recent logins. Restore the last clean copy before deleting anything, because evidence may still matter. Critical rule: do not drop an old backup over a database that already has new members without merging, or you lose real data.
What about a large database?
Big sites cannot export reliably from a browser; the file truncates. Use the command line or a scheduled plugin, and check the file size after export. A zero-byte or few-kilobyte file is a silent failure, and it is the most common reason a backup cannot be restored.
Start today
- Pick one backup method and run it now.
- Store the copy outside your hosting account.
- Write down the date of the last successful backup.
- Test a restore this month, even on a staging site.
Where exactly do you store it?
Three places are enough: personal cloud storage, an external drive, and a backup provider if the site sells. Never keep the only copy inside the site folder or on the same server. Name files by date, and keep a small text note explaining how to restore, because you may not be available when it is needed. Good backups are not always the newest; sometimes the copy before the last update is the one you want, so keep several points in time.
What if no valid copy exists?
Start with the database: can you export it from the panel? Then rebuild files from an older copy and import the newest database available. Ask the host whether they hold a side backup, and change every password. The lesson: testing a restore quarterly saves days of work at the worst possible moment.
A five-minute test is enough
Each month, restore a copy to a staging subfolder and confirm three things: the homepage opens, images appear, and you can log in to the dashboard. You do not need a full site test; if those three pass, the copy is practically sound. If one fails, you found the problem at a safe time instead of after losing the site.