Transparency

How We Test WordPress Backup Plugins

Every benchmark on Backup Arena is designed to be reproducible. This page documents the exact hardware, software, site profiles, timing rules, and verification checks so you can audit or replicate any result yourself.

Plugin Selection Policy

Backup Arena benchmarks the premium/paid version of every plugin. This ensures each plugin is tested at its full capability — not limited by free-tier restrictions.

If a plugin has no paid version (the free version is the only version), we test that. The goal is to evaluate every plugin at its best.

Benchmark Configuration

Before each backup run, the Worker configures every plugin to maximize scope and normalize compression, creating a level playing field. We never change plugin architecture (single zip vs. multi-zip, streaming vs. batch) -- only settings.

• Every plugin is configured to back up the maximum possible scope (database, plugins, themes, uploads, wp-config, and wp-core where supported).
• Premium plugins with wp-core backup capability have it explicitly enabled via WP-CLI option commands before each run.
• Plugins that do not back up certain components (e.g. All-in-One WP Migration excludes wp-core and wp-config.php by design) are noted on results pages with scope limitation badges.
• Compression is normalized to DEFLATE level 6 where configurable. Plugins that use proprietary formats or fixed compression are left at their defaults.
• Plugin architecture (single zip vs. multi-zip, streaming vs. batch, PHP ZipArchive vs. shell zip) is NOT changed -- each plugin runs its own engine.

Warm-up Iteration

Before the three measured iterations begin, a single warm-up backup runs on each container. The warm-up result is discarded and never included in rankings.

The warm-up primes PHP opcache, MySQL's InnoDB buffer pool, and the Linux filesystem cache. Without it, the first iteration would be penalized by cold caches, skewing the median.

• Both containers are reset to the clean snapshot state after the warm-up completes.
• All three measured iterations then run against a warm environment, producing consistent and comparable timings.
• Warm-up is applied identically to both plugins -- neither benefits from running first.

Backup + Restore Testing

Every battle tests BOTH backup and restore. A plugin must successfully create a backup AND restore it for the result to count. Plugins that crash during either phase automatically lose the battle (crash-as-loss).

Restore is tested by:

1. Loading a fresh snapshot into both containers
2. Each plugin creates a backup
3. The snapshot is reset to its original state
4. Each plugin restores from its backup
5. The restored site is verified against the original checksums

Backup Scope

Not all backup plugins back up the same data. Some plugins (like SafeGuard, Duplicator, BackWPup) create full-site backups including WordPress core files and wp-config.php. Others (like All-in-One WP Migration) only back up wp-content and the database — by design, they're migration tools rather than disaster-recovery tools.

Each battle result displays backup scope badges showing exactly what each plugin included. This lets you make informed comparisons: a plugin that's faster because it backs up less isn't necessarily better.

Scope-Weighted Speed Rankings

Speed rankings use scope-adjusted times. Plugins that back up less data receive a time penalty before determining the winner. This ensures that backing up less is not free -- a plugin cannot appear faster simply by skipping components.

Penalties per missing scope category:

For example, All-in-One WP Migration does not back up WordPress core files or wp-config.php, so its raw time receives a +4s penalty (3s for wp-core + 1s for wp-config) before the speed winner is determined.

Scope Detection — What a Backup Must Include

Backup Arena scores plugins on whether they actually back up everything WordPress.org's official documentation says they should. We use a tiered penalty system based on what each missing component would cost a real user during recovery.

Penalty table (effective from April 2026):

Citations

• WordPress.org Advanced Administration Handbook explicitly states wp-config.php must be backed up: “Pay particular attention to backing up... wp-config.php, which contains your connection details.”
• WordPress.org also confirms WordPress core is optional: “Normally, there would be no need to copy the WordPress core files, as you can replace them from a fresh download of the WordPress zip file.”
• This is why we keep the wp-core penalty modest (3 Elo) but penalize wp-config heavily (10 Elo).

Crash-as-Loss Scoring

If a plugin crashes during backup or restore (out of memory, timeout, PHP fatal error), the other plugin automatically wins that battle. This is fair: a plugin that can't handle a workload should lose to one that can.

Infrastructure failures (Docker issues, network errors) that affect both plugins equally are excluded from rankings entirely.

Server Specifications

Benchmarks run on a dedicated Hetzner VPS that serves no other traffic. The machine is reserved exclusively for benchmark execution to eliminate noisy-neighbor effects.

Docker Environment

Each battle spins up four fresh containers: two WordPress + two MySQL instances, one pair per plugin. Containers run on an internal Docker network with no outbound internet access.

InnoDB Configuration

Each MySQL container uses a custom configuration file mounted at /etc/mysql/conf.d/bench.cnf:

[mysqld]
innodb_buffer_pool_size = 1G
max_allowed_packet = 256M
innodb_flush_log_at_trx_commit = 0
tls_version=''

Hosting Profiles

Every battle is tested across six hosting profiles that simulate real-world infrastructure constraints. Rather than benchmarking on a single generous server, this reveals how each plugin performs under the resource limits your host actually imposes.

Each hosting profile runs 3 iterations per battle, producing 18 total iterations (6 profiles x 3 iterations). Resource limits are applied via Docker container constraints (CPU quotas, memory caps) so both plugins experience identical conditions.

Leaderboard rankings can be filtered by hosting profile, answering the question: "Which plugin wins on myhosting?" A plugin that dominates on a dedicated server may struggle on shared hosting with 256 MB of PHP memory.

Simulated Server Load

Real websites do not sit idle while a backup runs. During benchmarks, simulated server traffic runs in the background to test how each plugin performs under realistic conditions.

Four types of background load are generated:

• HTTP page views-- concurrent requests to the site's frontend pages
• Database queries -- SELECT/INSERT/UPDATE operations simulating plugin activity
• File I/O -- read/write operations simulating media uploads and cache generation
• WP-Cron tasks -- background scheduled tasks (email queue, post scheduling)

Load is applied at four intensity levels:

The same load level is applied to both plugin containers in a battle, ensuring fairness. This answers the question: "How does this plugin perform when my site has active traffic?"

Site Profiles

Seven pre-built WordPress sites cover the full spectrum from a fresh install to enterprise-scale. Each profile is a deterministic snapshot loaded identically for every battle.

Snapshot Format & Checksums

Each site profile is stored as a snapshot archive containing four components:

• wp-content.tar.gz -- compressed uploads, themes, and plugin files
• database.sql.gz -- gzipped MySQL dump
• metadata.json -- profile name, file count, DB size, plugin list
• checksums.json -- SHA-256 hash for every file in the snapshot

Before each battle, the Worker verifies the snapshot's SHA-256 checksum against the published value. The checksum for every profile is displayed in each battle's environment card and can be independently verified by downloading the snapshot.

Timing Methodology

Each battle runs three iterations. Before each iteration, both container pairs are reset to the clean snapshot state. Reset time (~10-20 seconds) is NOT included in timing -- the clock starts when the backup/restore command executes.

Phases

Each plugin's output is parsed into standard phases using a configurable phase parser:

Plugins whose output cannot be broken into phases receive a single BACKUP / RESTORE bar.

Archive Formats & Compression

Different backup plugins use different archive formats, which affects both speed and output size:

Compression directly affects the fairness of speed comparisons. A plugin that skips compression will appear faster (less CPU work) but produces a larger archive. Conversely, a plugin that compresses well takes longer but saves storage and bandwidth.

To address this, Backup Arena shows both raw timing AND storage metrics for every battle: archive size with format badge, compression ratio (archive size vs. raw wp-content), and throughput in MB/s. The three-winner system (Speed, Storage, Best Overall) makes these trade-offs explicit -- a plugin that skips compression wins on speed but loses on storage.

Backup Scope Detection

Not all backup plugins back up the same data. Some include everything (database, plugins, themes, uploads, wp-config.php), while others skip certain categories. This makes speed comparisons unfair if one plugin simply backs up less data.

After each backup completes, Backup Arena inspects the backup output to detect which categories were included. It examines file listings, ZIP/TAR archive contents, and WPRESS file headers, looking for patterns like .sql files (database), plugins/, themes/, uploads/ directories, and wp-config.php.

Results display scope badges (DB, Plugins, Themes, Uploads, wp-config) for each plugin. When the two plugins have different scopes, an amber warning banner appears indicating that results may not be directly comparable. This gives readers the context they need to interpret timing differences fairly.

Winner Determination

Each battle determines three winners:

• Speed Winner -- the plugin with the lowest median total time (backup + restore). If the margin is less than 0.5 seconds, speed is declared a draw.
• Storage Winner -- the plugin that produces the smallest median archive size. If the difference is less than 1 MB, storage is declared a draw.
• Best Overall (Pareto) -- a plugin wins Best Overall when no competitor beats it on BOTH speed AND archive size. This is based on Pareto optimality-- the same approach used by compression benchmarks like Squash and lzbench. If one plugin is faster but the other produces a smaller archive, neither dominates and the result is "Different Strengths."

Speed draws do not affect Elo ratings. Best Overall Elo only changes when one plugin Pareto-dominates the other; "Different Strengths" results count as draws with no Elo change.

Restore Verification

Every restore is verified with four independent checks. If a plugin produces a corrupted restore, it is caught and shown publicly in the battle results.

Result: verified: true/false per plugin per iteration, displayed in every battle result.

Post-Restore Site Verification

In addition to file and database integrity checks, Backup Arena performs automated functional checks after each restore to verify the site actually works:

• Homepage returns HTTP 200
• WordPress login page is accessible
• Post count matches the original snapshot

For WooCommerce profiles, additional checks are performed:

• Product count, order count, and customer count match the original snapshot
• A random product is spot-checked for correct price and stock data
• A random order is spot-checked for correct line items and total

Failed verification is logged but does not automatically disqualify the result. Some plugins legitimately change URLs or rewrite certain options during a restore (e.g., migration-oriented tools), so a verification failure is flagged for transparency rather than treated as a crash.

Execution Modes

Backup Arena offers two execution modes. Users choose the mode when starting a battle, and the mode is displayed on every result page.

Parallel Mode (default)

Sequential Mode

Security

Benchmark containers are sandboxed to prevent any plugin from affecting the host system or other battles.

• Docker containers run on an --internal network with no outbound internet access
• Plugin commands are parameterized templates -- never executed as raw shell input
• Fresh containers are created for every battle and destroyed afterward
• backup_output_path is validated at three layers: frontend form, API endpoint, and Worker before every docker cp command
• Submitted plugin zips are inspected for path traversal, symlinks, PHP outside expected directories, and zip bombs (decompressed size must be < 10x compressed)
• Plugin submissions are never auto-approved -- each requires manual admin review in an isolated Docker container with no network access

Reproduce Locally

All site profile snapshots are available for download. You can load them into the same Docker setup and run the benchmark scripts yourself to independently verify any result.

# Pull the benchmark containers
docker compose -f docker-compose.bench.yml up bench-wp-a bench-db-a

# Load a snapshot and run a backup
docker exec bench-wp-a wp [plugin] backup ...

# Compare your timings against published results