Five WordPress backup methods I tested: real restore times

A backup you have never restored is a guess, not a backup. Most guides stop at “set up automated backups and store them offsite,” which is the easy 20 minutes. The hard part is the restore, and that is the part nobody times until a site is already down and the client is on the phone.

So we did the boring thing. We took one real WordPress site (a WooCommerce store, about 4GB of files and a 1.2GB database) and restored it five different ways, timing each one and noting where it tripped. Here’s what actually happened, fastest to slowest, with the failure that bit us on each.

1. Host snapshot restore: fastest, least portable

On CyberPanel (and most decent panels) the host takes a full-server or per-account snapshot. Restoring the store from a nightly snapshot took 6 minutes and put files and database back together in one shot. Nothing to reassemble, no plugin to trust.

The catch: a snapshot lives on or near the same infrastructure. If the whole server or the provider account is gone, so is the snapshot. It is the fastest restore and the weakest disaster copy. We treat host snapshots as the “oops I broke a plugin update” layer, never as the only backup.

2. Staging clone, then promote: 18 minutes, safest to verify

Clone the live site to a staging subdomain, restore the backup there, confirm it actually loads, then push staging to production. On our stack this took about 18 minutes end to end, most of it copying files twice.

This is the only method on the list where you see the restored site working before it touches production. For an ecommerce site mid-sale, that confidence is worth the extra ten minutes. The gotcha is search-and-replace: the database is full of the staging URL after the clone, and if the promote step misses a table (serialized data in page builders loves to hide), you get mixed-content and broken layouts. We run wp search-replace with --precise and check the options table by hand.

3. UpdraftPlus from remote storage: 25 minutes, one nasty default

UpdraftPlus is the plugin most of these sites already had. Restoring its backup from Google Drive took 25 minutes, and most of that was the download and unzip inside PHP. It worked, but two things nearly bit us.

First, the free version splits large backups into archive chunks, and if one chunk fails to download you get a restore that looks complete and silently isn’t. Second, PHP timeouts: on shared hosting a 1.2GB database import will hit max_execution_time and die halfway, leaving the database in a mangled state. We raised the limit over WP-CLI before restoring rather than trusting the browser.

4. wp-cli plus mysqldump: 30 minutes, no surprises

The manual route: wp db import for the database, rsync or a tarball for wp-content, done. It took 30 minutes including the offsite pull, and it is the method we trust most on a broken box because nothing hides behind a plugin UI. When a restore has to work, this is what we reach for.

It is also the least beginner-friendly. You need shell access, you need to know which tables to keep, and one wrong --all-databases can flatten a neighbour site on a shared box. Power and foot-guns come together.

5. All-in-One WP Migration: easy until it isn’t

The one-click export/import plugins (All-in-One WP Migration, Duplicator) are the friendliest to use and the first to fail at scale. On this 4GB site the free tier refused the import outright over its upload cap, and the workaround pushed the restore past 40 minutes. On a small brochure site under 512MB these plugins are genuinely the quickest path for a non-technical owner. On anything with real product data, they hit a wall.

What the timings actually tell you

The ranking above is not the point. The point is that every method has a failure mode you only find by running it: silent chunk failures, PHP timeouts, missed search-replace, upload caps. A backup job that runs green every night tells you the backup was written. It tells you nothing about whether it restores.

So the rule we give every client is simple: schedule a restore drill. Once a quarter, restore last night’s backup to a staging site and load it. Time it. If it takes 40 minutes and you assumed 5, better to learn that on a Tuesday than during an outage. This restore-first thinking is the whole basis of the backup strategy we actually run. A 3-2-1 policy is only as good as your last successful restore.

The setup we recommend

For a site that matters, we layer three of these: a host snapshot for fast rollback, a plugin or wp-cli backup pushed to remote storage for the offsite copy, and a scheduled staging restore to prove the offsite copy works. That covers the “I broke something” case, the “the server is gone” case, and the “does this even restore” case that most setups skip.

If you would rather not run drills yourself, testing restores is part of our WordPress support work, and when a site is already down and the last backup won’t restore, that is a WordPress restoration job. Either way, find out your backup works before you need it to.