Talk about backups and most people picture a single lump called “the full backup”. But a WordPress site is made of three quite different things, and they change at different rates and restore along different paths. Manage them as one lump and an incident leaves you with only two choices — roll everything back, or roll nothing back.
The first step in backup design is not picking a tool. It is separating the parts.
The three parts of a site
Code — not really a backup problem
Code changes only when a person deploys it. So if it lives in version control, your backup is already the repository. You can return to any point in its history, and you can see who changed what.
Which means the real backup targets on the code side are the things that never go into the repository: wp-config.php with its database credentials and security salts, the nginx and PHP configuration, TLS certificates and their renewal setup, scheduled jobs, and any file someone uploaded by hand through an admin screen. These are tiny, and without them a restore stops dead.
If your code is not in version control, then code is data too — nobody knows which file changed, when or why, so the whole tree has to be copied. Getting out of that state is the single biggest thing you can do to make backups simple.
The database — changes most, and is usually smallest
Posts and pages, site settings, user accounts, orders and enquiry records all live in the database. It changes whenever anyone visits, and it changes when nobody visits because scheduled tasks are running.
It is also, in most sites, the smallest of the three: text and settings do not weigh much. Small and constantly changing is a useful combination — taking it often costs little, and there is every reason to take it often. The restore path is simple too: import one dump file.
Uploads — largest, and mostly append-only
wp-content/uploads/ is usually most of your backup volume. Its behaviour is distinctive, though: existing files rarely change, new ones are added. That calls for incremental synchronisation rather than copying everything each time. Insist on full copies and the volume slows your schedule down — and the database gets dragged along with it.
This is also what makes “restore the database only” possible, the subject of part five. If all three are inside one archive, that option simply does not exist.
How far to extend backups into server configuration and certificates is covered in the Servers & infrastructure archive, and if you would like an existing site’s backup arrangement reviewed, that is part of the diagnostic in our optimization program.
Next part
With the targets settled, frequency is next. The following part works it out — not from a convention like “nightly”, but from how much time you can afford to lose.