Back up a quiet WordPress site about weekly, a busy one daily, and every site before an upgrade or move. Keep three to five recent copies in different places. A backup you have never restored is a guess, so test the restore on a staging copy at least once a quarter.
What the WordPress documentation recommends
The official backup guide separates a WordPress site into two parts. The database holds every post, comment and link, and it lives apart from the WordPress directory, so copying files does not back it up. The files hold core, plugins, themes, uploads and code. You need both to restore a typical site.
On frequency, it suggests about once a week for small sites with few posts and daily for high activity sites, and always before an upgrade or a move. It also advises keeping at least three to five recent backups and storing them in different places, such as the host, cloud storage and a local computer.
| Site type | Suggested rhythm |
|---|---|
| Brochure site, few edits | Weekly |
| Blog or shop with steady activity | Daily |
| Any site before an upgrade or move | Immediately before |
Order matters
Back up the database first, then the files. On restore, put the files back first, then import the database. If database credentials changed, update the wp-config.php file to match. Writing this order into a runbook saves time when someone is under pressure.
What a restore test looks like
- Pick a recent backup, not the freshest one only.
- Restore the files and database to a staging site, not production.
- Fix the site address and credentials in the configuration.
- Load the home page, log in, open a recent post, submit a form, and check media.
- Record how long it took and what broke.
- Fix the runbook, then repeat next quarter.
The documentation itself only advises checking automatic backups against a manual one now and then. It does not describe a restore drill, so treat the steps above as a practice suggestion, not an official procedure.
Protect the backups
The hardening guide recommends keeping dated snapshots so you have copies from before and after a compromise, and protecting integrity by encrypting backups, keeping independent hashes, or using read only media. Backups often contain customer data and secrets, so give them the same access control as the live site.
Common gaps
- The backup plugin writes to the same server it protects.
- Nobody owns the schedule and nobody checks the result.
- Only files are copied, or only the database.
- Retention is one copy, overwritten nightly, so a slow compromise is backed up too.
If you also want to see what your site depends on before something goes wrong, Safeguard can scan a repository for dependency manifests and produce an SBOM, and there is a free scan at gold.safeguard.sh/scan.
Quick check
Which do I restore first, files or database?
Files first, then import the database, then fix credentials in wp-config.php if they changed.
How many backups should I keep?
The documentation suggests at least three to five recent ones, stored in different places.
Sources
Last reviewed: 19 October 2026.
