Incremental encrypted copies stored off-site, a restore point before every update, and scheduled restore testing that boots the backup and confirms it works. Recovery is one click, and you can prove the copy is good before the day you need it.
Included on every plan. No add-on pricing.
Updated
A WordPress backup is a copy of everything a site needs to be rebuilt: its database, which holds posts, pages, users and settings, and its files, which hold WordPress itself, themes, plugins and uploads. A backup is only useful if it is stored away from the site it protects and can actually be restored.
WPCentrify backs up every WordPress site you connect from one dashboard and stores the copies off the website. After the first full copy, parts that have not changed are reused rather than copied again, and large databases are read in pieces sized to what the host allows, so a backup does not time out on a big site. Our guide on how to back up a WordPress site covers the methods and how often to run them.
Almost every WordPress site has a backup plugin installed. A much smaller number have a backup that would actually restore. The failure modes are boring and common: the plugin hit a PHP timeout partway through a large database, the destination filled up, credentials expired, the schedule silently stopped after a plugin conflict, or the backup has been running perfectly for two years to a folder on the same server that just got wiped.
None of these produce an alert, because the plugin believes it succeeded. You discover the truth during an incident, which is the worst possible moment to learn something new about your infrastructure.
After the first full copy, only what changed is transferred. Backups complete in seconds rather than hours, do not hammer the host, and do not time out on large databases. Sites with large media libraries stay practical to back up daily or better. Where a database has never been cleaned, that is usually what makes a backup slow, which is what database cleanup across multiple sites addresses.
AES-256 encryption at rest, TLS 1.3 in transit, stored on separate infrastructure, never on the same server as the site. Bringing your own S3-compatible bucket, for backups that must live inside your own account, is planned.
Any update or bulk action takes a fresh snapshot first. Rollback never depends on last night's scheduled run, which may be nineteen hours old and missing the orders that came in this morning. That snapshot is what lets safe WordPress updates undo themselves.
WooCommerce sites can back up order and customer data continuously rather than on a schedule, so a restore does not lose the transactions that arrived between backups.
On a cadence you set, WPCentrify restores a backup into an isolated sandbox, boots WordPress, checks the database imports, confirms the home page and admin respond, and records a pass or fail.
Each test produces a dated record. "Backup verified 3 September, restore completed in 2 minutes 14 seconds" is a much better answer to a nervous client than "backups are running".
Restore a whole site, a single file, a plugin folder, or an individual database table. You do not have to roll the entire site back to fix one broken thing. The full set of restore paths and how they are tested is covered on the restore page. If a site is hacked, Sentinel points you to the last backup taken before the first sign of the hack.
Because tests measure real restore duration, you know your actual recovery time objective per site instead of guessing at it.
What people ask before they turn this on.
In encrypted storage in the United States on OVHcloud servers, never on the same infrastructure as the site being protected. Using your own S3-compatible bucket, so backups sit inside your own account, is planned.
It depends on site size, but restore testing measures it for you. A typical 3GB site restores in two to four minutes. Because the test runs on a schedule, you always know your real recovery time rather than estimating it.
Yes. Restore a full site, files only, database only, a single table, or an individual file. Selective restore is usually the right tool when one plugin has corrupted its own settings.
You can download everything before you go, and there is a grace period after cancellation during which exports remain available. Backups are never held to encourage you to stay.
It can, and it is usually better because it is off-site, tested and granular. Many people keep both. Host backups tend to be full-server snapshots with coarse restore options and no verification.
At least once a day for a site that changes often, such as a store or a busy blog, and before every update. A site that rarely changes can be backed up less often, but a daily backup costs little and shortens how much work a restore can lose.
Use one tool that backs up every site to storage away from the sites themselves, and that shows you in one place which backups failed. WPCentrify backs up every connected WordPress site from one dashboard, stores the copies off the website, reuses unchanged data to keep backups fast, and alerts you when a backup fails.
Not with WPCentrify. Backups are taken through the WPCentrify connector plugin that each site already runs, so there is no separate backup plugin to install and keep updated on every site.
Yes. You can download a restore point's database as a SQL file that imports into any MySQL or MariaDB server, so your backups are never locked inside WPCentrify.
WPCentrify reads a site in small pieces sized to what its host allows and slows down when the server is busy, so a backup does not overload a shared host. After the first full copy, unchanged data is reused, which keeps later backups short.
Every update is preceded by a restore point
Read moreDetect the compromise that makes you need a restore
Read moreOrder-safe backups for stores
Read moreMore on this topic: How to back up a WordPress site · How to restore a WordPress backup safely
Connect a site in under two minutes and see this working against something real. Free during early access.
Free during early access. Keep your data, export any time.