Why Your WordPress Backup Takes 30 Minutes (And How to Fix It)

You hit "Backup Now," then go make coffee. You come back, the bar is at 28%. You make lunch. Still going. Eventually you give up and just leave the tab open.

This is normal for WordPress, and it shouldn't be. The reasons are the same handful of design choices, repeated across most popular backup plugins for the better part of a decade.

What's actually slow

There are three usual suspects, and they almost always show up together.

Full file scan, every run. A typical small business site has 7,000 files. A WooCommerce store with a few thousand products and order history can blow past 200,000 files between uploads, plugin assets, and cached data. Most plugins read all of them on every backup, even if you only changed a footer link since yesterday. On shared hosting where disk I/O is throttled, that single pass eats minutes.

No change detection. If the plugin can't tell what changed, every backup is a full backup. You added one image; it re-archives 2 GB. You fixed a typo in a post; it re-exports the entire database.

Single-process PHP. WordPress is PHP, and PHP is single-threaded by default. Most plugins do the entire backup in one synchronous run. They hit max_execution_time (often 30 seconds on shared hosts), then either fail silently, restart from zero, or both. You see "Backup interrupted, retrying..." and the cycle starts over.

There's also a subtler one specific to ZIP archives: a flush pattern where the plugin closes and reopens the archive every N files to avoid memory pressure. It works, but on large sites it turns a 30-second job into 30 minutes. We dug into this when a competitor benchmark showed Duplicator at 33 minutes on a 40K-file site. The fix in our code was a one-line change, and the difference is the gap you'll see in the numbers below.

The numbers

Backup Arena is an independent benchmark site that runs WordPress backup plugins against the same fixed snapshots inside Docker, back-to-back. We submit our plugin like everyone else, the runs are reproducible, and the data is public.

As of April 2026, across 58 head-to-head battles:

SafeGuard's win rate is 87.9%. AIOWM has more wins per match but uses a non-portable archive format (.wpress) that no other tool can read; it loses on integrity, not speed. Duplicator at 40 seconds median is the closest thing to "30-minute backup" you'll see in modern numbers, and it gets significantly worse on larger sites.

Concrete head-to-heads on the WooCommerce Heavy profile (221,709 files, 488 MB database):

• SafeGuard 16.90s, UpdraftPlus 26.86s
• SafeGuard 17.03s, Duplicator Pro 35.33s
• SafeGuard 16.98s, BackupBuddy 22.24s
• SafeGuard 16.99s, Duplicator (Lite) 106.55s

Same Docker host, same snapshot, same MySQL, same iteration count. The gap on smaller sites is narrower because there's less data to be slow with. The gap on bigger sites widens, because that's where the design choices above matter.

How incremental actually works

The shorthand "incremental backup" gets used to mean a few different things. What it means in SafeGuard:

The first backup of a site is full. Every file gets read, hashed, and archived. We store the hash list alongside the archive in a binary index file (hash-index.bin).

The next backup re-walks the filesystem and compares each file against that index using a four-tier check:

1. mtime: the filesystem's modification timestamp. Cheapest. Catches most edits.
2. size: for files where mtime didn't change but content did (atomic writes, sync tools).
3. content hash on critical files: wp-config.php, .htaccess, wp-cron.php. We always hash these regardless of mtime, because security depends on noticing when they change.
4. content hash on the rest: only when mtime or size flagged something. We use xxh3 if PHP 8.1+ is available, MD5 otherwise. xxh3 is faster, MD5 is universal.

Files that haven't changed are skipped entirely. Not re-read, not re-compressed, not re-archived. The plugin's job for unchanged files is to confirm they're still in the previous archive and move on.

On a typical day with a few CSS tweaks and one new product image, that's 99% of files skipped. The backup that took 16 seconds the first time runs in under 3.

The shared hosting problem

Most of the WordPress sites we run into are on shared hosting: cPanel, SiteGround, Bluehost, Hostinger. The ones that matter for backups:

• max_execution_time: usually 30 seconds, sometimes 60. Hit this and PHP is killed mid-task.
• memory_limit: 128 MB or 256 MB on most shared plans. Some plugins need 512 MB and just fail on shared hosts. WPvivid OOMed on the 40K-file snapshot at 512 MB during the lab runs.
• Disk I/O throttling, invisible until you do something I/O heavy like a backup.

Building for these constraints rules out a lot of architectures. SafeGuard's loop runs in 25-second work chunks, then hands off to Action Scheduler to pick up the next chunk. If a chunk crashes, the next one resumes from the same spot. The end user sees a backup that "took 4 minutes" without realising it was actually six 25-second runs stitched together.

The same pattern applies to memory. We size database row batches based on memory_get_usage() and the available headroom. A site that's hitting its memory ceiling gets smaller batches; a site with room to spare gets bigger ones and finishes faster. There's no "minimum 256 MB required" line in the readme.

What we don't claim

A few things worth being honest about:

• AIOWM is faster than us on small sites. Their .wpress format trades portability for speed. If you only ever use AIOWM, that trade is fine. If you ever want to extract a backup manually or hand it to someone else, it's a problem.
• BackWPup is competitive on small sites because it does very little processing. On larger profiles the gap opens up.
• The first backup is always slower than subsequent ones. That's how incremental backups work; there's no way around it. If you're benchmarking us against another plugin's first run, expect a closer race.
• The numbers above are server-side time. They don't include the upload to S3/Dropbox/etc. That part depends on your network and the provider's API; a 200 MB archive going to Wasabi from a US-East shared host will be much faster than the same archive going to OneDrive from a Cairo VPS.

Try it

SafeGuard is in early access. The plugin is free to install for the duration of the beta, and the early access tier locks in founding-member pricing.

Get Early Access →