If you look after ten or twenty client sites, backups are not a feature you evaluate. They are the thing that decides whether a bad Tuesday costs you an hour or a client. The routine below is deliberately boring. It uses Backinator, the free backup plugin from Web9, and it is built around one question: can you bring this site back on a fresh server, by yourself, without anything from the old one?
What a backup has to contain
A usable backup is the database and the files together, from the same moment, in one archive you can move. Backinator builds exactly that. The backup wizard has three steps, Setup, Scan and Build, and the result is one archive (files and database, or database only) plus an installer.php file.
The archive is written in resumable steps (scan, database dump, files, verify, installer, encrypt, upload), so a large site does not depend on one long PHP request finishing. The job continues across requests, driven by the browser while you watch it or by cron when you do not.
Archives land in wp-content/backinator-backups/, outside the plugin folder, so updating or deleting the plugin never deletes a backup.
The standalone installer
This is the part that makes the routine work. The installer.php next to the archive does not need WordPress, the old server or the plugin. Upload both files to an empty folder on any host, open installer.php in a browser, and enter the database details for the new location. The installer unpacks the files, imports the database, and rewrites URLs, paths and the table prefix, including values inside serialized data and page-builder JSON.
For a restore on the same server, the Restore button on any backup runs the same installer. The live site keeps running until the last step, so a restore that fails part way leaves the site as it was. A “clean restore” option removes files in wp-admin, wp-includes and wp-content that are not in the archive, so the result mirrors the backup rather than layering it over whatever was there.
Encryption and the password
Archives are encrypted by default with XChaCha20-Poly1305, using a key derived from the site’s backup password with Argon2id. That password lives in the plugin’s Settings screen. It is also the only way to open an off-site copy if the server is gone, so it belongs in your password manager, stored per site, the day you set it.
The routine
Here is what to do for each site, once.
- Install Backinator and set the backup password. Save the password to your password manager under the client’s name.
- Configure off-site storage. Backinator supports S3-compatible services (AWS S3, Cloudflare R2, Backblaze B2, Wasabi, MinIO), Google Drive, or a plain folder such as a mounted NAS. Pick one bucket or folder per client. Each storage keeps the newest N backups, so set N to cover the window you need.
- Create a schedule. Schedules run hourly, daily, weekly or monthly in the site’s timezone. For a brochure site that changes monthly, weekly is enough. For a shop or a site with forms writing to the database, daily. Run it at a quiet hour.
- Run one backup by hand and download it. Do not trust a schedule you have not seen complete. Keep this first archive and its installer locally.
- Test the restore on a throwaway host. Take that archive and installer, put them on a subdomain or a local server, and run the installer. If it comes up, the routine works for this site. If it does not, you found out on a calm day.
Then, on a recurring basis:
- Weekly: glance at the backup list on the sites that matter most, and check that the newest archive reached storage.
- Quarterly: do a test restore of one site, chosen at random. Rotate through clients so each one gets tested at least once a year.
- Before every major change: a plugin update that touches the database, a theme swap, a migration. Run a manual backup first. It takes a few minutes and makes the change reversible.
Moving a site
Migrations are the same operation as a restore, in a different folder. Build a backup, upload the archive and installer to the new host, run the installer with the new database details, and point DNS at it when it looks right. There is no plugin to install on the destination first.
Going the other way, Backinator’s Import screen accepts an archive from another site by drag and drop. The upload is chunked, so PHP’s upload size limit does not get in the way, and it can also pull an archive back from configured storage.
Requirements
Backinator needs PHP 7.4 or later with the zip, mysqli and sodium extensions, all of which ship with a standard PHP build, and WordPress 5.8 or later. It does not support multisite.
Why a plugin and not the host’s backups
Host backups are worth having, but they are tied to the host. If you leave, or the host has an outage, or the account is suspended, you may not be able to reach them. A backup you can download, encrypt with your own password and restore anywhere is yours regardless of where the site lives. Use both. Rely on the one you control.
