Back up both the site files and the database, because a typical WordPress site stores them separately and needs both to restore. Keep copies in more than one location, take one before every upgrade, and test a restore on a schedule so you know it works.
This follows the WordPress handbook's guidance on backups, which this post summarises for agency use.
The two halves
The handbook explains that the files are the WordPress directory: core, themes, plugins, uploads, wp-config.php and .htaccess. The database sits in MySQL or MariaDB outside that directory, and you usually cannot capture it by copying files. You export it as a dump file.
| Part | Contains | How it is captured |
|---|---|---|
| Files | Core, themes, plugins, uploads, config | Copy or archive the directory |
| Database | Posts, settings, users, plugin data | Export a dump |
The handbook's recommended order is database first, then files, treated as one backup set. To restore, it says files first, then import the database, and update wp-config.php if credentials changed.
How often and how many
The handbook suggests weekly backups for smaller sites and daily backups for high activity sites, and always before an upgrade. It recommends keeping at least three to five recent backups, with copies in different locations, for example on the server, in cloud storage and on a local computer. It also advises backing up your automatic backups manually from time to time to check the process works.
For a client with a webshop, daily is a floor. Orders written to the database between backups are lost on restore, so ask the client how much loss is tolerable.
Protect the backup itself
A backup holds the same data as the live site, including user records. Treat it with the same care: restrict who can download it, store it in a client owned location, and do not leave dump files in the web root. The WordPress hardening guide stresses keeping sensitive files out of reach, including wp-config.php, which holds database credentials.
A restore test you can run in an hour
- Create a blank staging site or local copy.
- Restore the latest files, then import the database.
- Update the configuration for the staging address.
- Log in, open a few pages, submit a test form.
- Write down the time taken and anything that failed.
Do it quarterly. Repeat after any change of host or backup tool.
What to record in the handover
Record the schedule, locations, who owns each location, the date of the last successful restore test and who can perform one. That one line, "last restore tested on this date", is worth more than any claim about backup tools.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how ongoing checks raise an alert without a manual run, which is how a missed backup should be noticed too.
Safeguard's free scan covers dependencies in a repository, not site backups, so use it alongside your backup routine, not instead of it.
Quick check
Does backing up the files also back up the database?
Not in a typical setup. The database is stored outside the WordPress directory, so you must export it separately.
How many backups should I keep?
The WordPress handbook suggests at least three to five recent backups in different locations.
Sources
Last reviewed: 19 October 2026.
