A WordPress Backup Strategy You Can Actually Restore

People frequently discover mid-crisis that their backup contained half of what they needed. A WordPress site is two things, and you need both from the same moment in time:

• The database: posts, pages, products, orders, users, comments, and every plugin and theme setting. This is where the site's content and configuration live.
• The files: wp-content in particular — your uploads, themes and plugins. Core files can be reinstalled, but your uploads directory cannot.
• Taken together and taken consistently. A database from Tuesday with files from Friday can leave you with posts referencing images that don't exist yet, or a plugin's settings for a version that isn't installed.

The right frequency is a business question, not a technical one: how much work can you afford to redo? For a brochure site updated monthly, a weekly backup is fine. For a store taking orders every hour, a daily backup means you could lose a day of orders, which almost certainly isn't acceptable.

Retention matters as much as frequency. Compromises are often discovered a week or two after they happen, so keeping only the last three days means every copy you have may already be infected. Keep a rolling window of recent backups plus a few older monthly ones, so you can reach back past a problem you didn't notice.

Take an extra manual backup before anything risky: a major WordPress update, a plugin migration, a theme switch, or a bulk content import.

Not on the web server. If the backup is in a folder on the same account as the site, then a server failure, a ransomware infection or a suspended hosting account takes the backup with it. It's also publicly reachable if the folder isn't protected, which occasionally means a site's full database is downloadable by anyone who guesses the path.

Send backups off-site — object storage, a cloud drive, or the backup service's own storage — and keep the credentials for that destination somewhere other than the site you're backing up. If a compromise gives an attacker your WordPress admin, it shouldn't also give them the ability to delete your backups.

A useful rule of thumb: three copies, on two kinds of storage, with one off-site.

• Host backups are usually automatic, cheap and taken at the infrastructure level, which makes them consistent. They're also often restore-all-or-nothing, and they disappear if you leave the host.
• Plugin backups give you control over frequency, destination and granular restores — a single file, a single table. They run inside PHP, so on a large site they can time out or put load on the server.
• The sensible answer is both. Host backups as the safety net you don't have to think about, and a plugin or service backup as the one you control and can take with you.

This is the step everyone skips, and it's the only one that proves anything. Once a quarter is enough for most sites.

• Spin up a staging site and restore the most recent backup into it, start to finish.
• Time it. Knowing a restore takes forty minutes changes how you handle an outage; discovering it takes six hours during the outage does not.
• Check the details: do images load, do the plugin settings look right, is the most recent content there, does the checkout work?
• Confirm you can actually access the backup destination — expired credentials are a common and silent failure.
• Write down the steps. During an emergency at 11pm is the wrong time to be working out the process from scratch.

Backup jobs fail quietly. Storage fills up, an API token expires, a plugin update changes a setting, a site outgrows the PHP time limit. The first sign is usually that the backup you need doesn't exist.

Turn on failure notifications, and check the backup list yourself every month — not to admire it, but to confirm the most recent entry has a recent date and a plausible file size. A backup that suddenly shrank by 90% is a broken backup, not an efficient one.

Restoring a hacked site has an extra step that people miss: if you restore the same vulnerable plugin that let them in, you're back where you started within days.

Take a copy of the compromised site first, so you can work out how they got in. Restore from a backup taken before the compromise, which is why retention depth matters. Then update or replace whatever was vulnerable, rotate every password and the salts in wp-config.php, and check for accounts and scheduled tasks that were added while they had access.

• Daily automated backups of files and database for an active site, weekly for a static one.
• Stored off-site, with credentials held outside the site.
• Thirty days of daily copies plus a few monthly ones.
• Failure notifications on, and a monthly glance at the backup list.
• A restore test to staging once a quarter, with the steps written down.
• A manual backup before every risky change.