WordPress backup built for fleets
Incremental backups on a schedule you control, stored where you choose, with point-in-time restore that keeps the site online. One dashboard shows backup health across every site so nothing falls through the cracks.
A clean backup on record before every change
A WordPress backup strategy that relies on nightly full-site archives creates two problems: storage bloat from redundant copies, and a restore point that is always hours behind the most recent change. WPMgr uses content-addressed incremental backups, recording only what changed since the last run. Before every plugin update or manual change, a pre-flight backup fires automatically so you always have a clean snapshot to fall back to. Restores run without taking the site offline. The fleet-wide backup health view flags sites with missing or stale backups before a client notices. And the database cleaner pairs with backups to keep the database lean before and after each snapshot.
The features that prove it
Everything listed below ships in the free, open-source release with no add-on required.
Common questions
Specific questions about this use case.
How are incremental backups different from full backups?
A full backup copies the entire site on every run, which means every archive is a complete duplicate of the previous one. WPMgr uses a content-addressed chunk store so only the blocks that changed since the last run are written. The result is faster backup jobs, far less storage, and a complete restore chain that can recover to any point.
Where are backups stored?
In the self-hosted release, backups are stored in the destination you configure: a local path on the server, an S3-compatible object store, or another remote location. The hosted cloud version will offer managed remote storage. You own the destination; WPMgr handles the scheduling and transfer.
Can I restore a single database table without a full restore?
Full point-in-time restore is the current focus. Per-table or per-file granular restore is on the roadmap as an incremental backup phase.
How does the fleet-wide backup health view work?
The backup health browser shows every site in your fleet with its last successful backup timestamp, the backup size trend, and a health indicator. Sites with no recent backup, a failed job, or a schedule gap are flagged so you can act before a client asks.
Does the database cleaner affect backup size?
Yes. Running the database cleaner before a backup removes accumulated post revisions, transients, orphaned meta records, and other bloat, which directly reduces the snapshot size and the time it takes to restore.
Run your whole fleet from one dashboard.
Free and open source. No per-site fee. The full release is on GitHub.