How to manage backups across WordPress sites

Decide how often each site needs a backup. Weekly may be enough for a low-activity brochure site, while a busy shop or publishing site may need daily database backups. Always create a fresh backup before WordPress, plugin or theme updates. WordPress recommends keeping at least three to five recent copies in different locations.

Keep a record of each site, its backup schedule, storage destination, retention period and the last successful restore check. Do not treat a host snapshot as your only copy.

For each site, download the complete WordPress file set using SFTP, including wp-content, the themes, plugins, uploads, configuration file and the rest of the installation. Then export the WordPress database from phpMyAdmin or your host’s database tool. Files and the database are separate; backing up only one leaves part of the site unprotected.

This manual route is fine for one or two sites and gives you direct control. Its drawbacks are easy to underestimate: every site needs separate work, schedules are easy to miss, files can fill the server, and an export that was never restored is only an assumption. Store the database export with the matching file backup and label both with the site name and date.

Send backup copies to storage that is separate from the WordPress server, such as approved cloud storage, and keep at least one local or independently controlled copy. If malware, a hosting failure or an accidental deletion affects the server, a backup stored on that same server may disappear with it. WordPress also recommends keeping copies in different locations.

Set a retention rule so old archives are removed only after newer copies have completed successfully. Protect the storage account with strong access controls, and encrypt sensitive archives where your backup system supports it.

Review the result after scheduled jobs run. Confirm that the database and files were included, the archive has a sensible size, the destination accepted the files, and the log reports success rather than a warning or error. BackWPup creates a log for each job and records its status, saved content, size and runtime.

The Friday failure to watch for is a job that appears scheduled but silently stops because of storage limits, expired remote credentials, a timeout or a permissions problem. A green-looking schedule is not proof that a usable backup exists.

Restore a recent backup to a staging site or separate test installation on a regular schedule. Check the front end, log in to WordPress, open key pages, test forms and confirm that uploaded media and important plugin data are present. A backup is not proven until you can use it to recover the site.

For a typical restore, put the files in place first and then import the database. If database credentials change, update wp-config.php to match. A move to another domain or host may also require a careful database URL replacement after taking a backup.

When you manage several WordPress sites, the fast route is to use MainWP BackWPup Extension with the BackWPup plugin installed on each child site. From the MainWP Dashboard, you can create and schedule jobs across child sites, run backups on demand, review logs, and manage backup files from one place.

Set up one consistent job for similar sites, then adjust schedules and storage for sites with different traffic or data requirements. Confirm the extension and BackWPup versions are compatible, and still perform periodic restore checks; central management reduces repetitive work but does not replace verification.