25 WordPress backup tools to match your recovery needs

A useful backup must be able to leave the server and come back

You are preparing an update or want to recover your site after an outage. The desired result is more than a ZIP file visible in WordPress: it is a set of files you can access when needed, with a restore process you understand. The database contains content and settings, among other things; the files include media and site components. A tool that protects only one of these parts must be supplemented.

These twenty-five product families serve different purposes: backing up a complete site, managing several installations, or keeping a database copy before maintenance. Free and paid editions of the same product are grouped together. A database-only copy remains a supplement: it does not replace the media, theme, and plugins needed for a full recovery. The profiles specify this scope to avoid comparing protection that does not cover the same incidents.

A local acceptance test restored a database and a file with UpdraftPlus. The other offerings are described according to their advertised features. Unverified retention rules remain flagged. Check storage and emergency access separately from the license.

Start by reviewing the setup already available

Before adding a plugin, ask what is currently backed up, where the copies are, and who can retrieve them. Hosting or an existing tool may already provide part of the setup. Check a recent report and a recovery point without starting a restore on the live site. A database-only job does not prove that media files have been copied.

Three approaches suit different organizations: keep an adequate existing setup, manage your own archives and their destination, or use a connector to backup infrastructure. This catalog describes these features in WordPress, without comparing hosting plans. For connected products, the external service is a dependency to examine, not automatic proof of superiority.

For a brochure site that changes occasionally, a downloadable full copy, kept elsewhere and renewed after changes, may meet a simple need. For an active store, a manual monthly operation would leave a considerable gap. First choose a backup frequency and recovery procedure suited to the activity, then the product that can deliver them with the available access and budget.

• Check the scope, independence of the copies, and recovery process before installing anything.
• Define who manages the archives, storage access, and retention.
• Do not add multiple plugins when a single product family covers the need.

Distinguish local copies, external copies, and test copies

An archive created in the site folders stays on the same hosting account. An account outage, deletion, or loss of access can affect both the site and its copies. To call a destination external, verify that it really is separate storage whose access can still be recovered independently. An FTP transfer to the same server does not create this independence.

A test copy, often called staging, is used to examine a change without targeting the public site. It may share the disk and limits of the main installation. Ask two separate questions: where do you work for testing, and where do you retrieve the data if that hosting disappears? The presence of a clone does not demonstrate the existence of an external archive.

Read the scope and retention details before the promises

For each candidate, look for the included files, exported tables, and exclusions. A database-focused tool can be useful if the corresponding files exist elsewhere. Examine special cases: externally stored media, files outside the usual directory, third-party component tables, and a multisite network. If an essential item is not clearly covered, clarify the procedure before choosing the product for a critical site.

Frequency relates to how much work you are willing to lose between two copies. Retention indicates how far back in time you can go. Several months of retention with a monthly copy do not provide daily recovery points. Frequent copies that are quickly deleted may also be unavailable when an error is discovered late. Check both needs, then the local and remote cleanup rules.

Incremental backups keep changes after an initial copy. The differentials described by some tools group changes since a reference point. You must keep all the elements needed for the planned recovery process. Do not arbitrarily delete an old remote archive because it looks large. Confirm what is self-contained and what depends on a history.

Prepare the restore without risking production

Identify the person authorized to restore and the access they will have if WordPress no longer starts. Some workflows use an external dashboard; others use a script or file and database access. A button in the administration area is not enough if it becomes inaccessible during the problem you fear. Keep a private procedure, without publishing passwords or attaching archives to a forum.

A future test must target a separate, authorized, prepared environment. Payments, emails, notifications, and webhooks must be disabled there to avoid triggering real actions. The person responsible must check content, media, accounts, and important features after recovery, then record the operations actually performed. The local UpdraftPlus acceptance test described below covers the database and a marker file; it does not validate all these business workflows, external connections, or the other tools.

Restoring an old copy can erase legitimate changes made since then. Before an authorized recovery, if possible, save a new complete state of the currently accessible files and database, without overwriting the last healthy archive. Record the time of the selected point and the data received since: orders, accounts, forms, bookings, or stock changes. This safety copy does not make the old state usable; it preserves information to reconcile during recovery.

For a store, payments actually collected by the payment provider are not canceled by rolling the database back. With subscriptions, tasks already completed can even return to a pending state and trigger repeated processing. Have the technical lead prepare the recovery and reconciliation of recent data, with support from the component concerned. If new operations need to be suspended, arrange this before the switchover. Do not reinsert a few tables or a CSV file at random: orders, customers, subscriptions, and stock have relationships that must be preserved.

An order protection feature also depends on the workflow used. For example, Jetpack distinguishes restoring through its dialog from restoring individual tables: the latter can replace recent WooCommerce data. The word “selective” therefore does not guarantee its preservation. After a prepared recovery, check content, the latest business data, scheduled tasks, and access before fully reopening the site. If the copies are unreadable or the handling of this data remains undefined, stop the procedure and request targeted assistance.

Measure a store recovery before reopening

To choose a backup solution, set two limits with the person who manages the store: how far back you can go before having to reconstruct recent operations, and how long selling can remain unavailable. These are called the recovery point objective (RPO) and recovery time objective (RTO). The first is measured from the healthy point that can actually be recovered; the second runs from the interruption until service is restored. The duration advertised by the plugin covers neither obtaining access, nor checks, nor order reconciliation.

Fictional example, times in UTC: the store becomes unavailable at 14:00. The team accepts a maximum data gap of two hours and three hours of downtime. A 13:00 backup appears in the log, but a volume is missing from the download. The last complete recoverable copy is from 11:00. The gap is therefore three hours: you need to find a healthy point at 12:00 or later, or define how to reconcile operations since 11:00. This time window needs checking; it does not mean that all operations are lost.

In an isolated acceptance test, the archive is ready at 14:25, the restore finishes at 15:35, and the initial checks end at 16:10. The plugin worked for 1 hour 10 minutes, but 2 hours 10 minutes have already elapsed since the simulated incident. There are 50 minutes left before the 17:00 objective; recovery time has not yet been demonstrated because business discrepancies and reopening still need to be addressed. These times serve to illustrate the calculation; they do not describe the performance of any plugin.

• On an isolated copy, use a fictional data set. Record the time of the last complete copy, the interruption, and each step: recovering access, obtaining the archives, restoring, checking, and then deciding whether to reopen. Verify that the database and file dates match the selected point.
• Within the time window to check, prepare, for example, an order at 12:10, a refund at 12:40 for an older order, and a renewal at 13:20. Compare references, times, amounts, and statuses between the restored site, the retained order record, and the available payment records. An identical order total does not necessarily reveal a missing refund. In WooCommerce → Status → Scheduled Actions, observe the status of renewal tasks without running them; keep payments, emails, and external notifications disabled during the test.
• Decide based on the discrepancies. If you find a more recent healthy point, test it separately before replacing anything. If the cause is isolated to a file or setting, consider a targeted correction that preserves business data. If a full recovery is still necessary, keep the site closed to new writes while the technical lead reconciles orders, payments, refunds, stock, and renewals. If discrepancies remain unexplained, do not reopen the store solely on the strength of a successful restore message.

Assemble an identifiable recovery set before an incident

Prepare a private record for each set: site name, address, date and time with time zone, included components, exclusions, and remote location. Pair the database and files taken during the same period. The WordPress documentation distinguishes them: downloading the site folders does not automatically retrieve the content stored in MySQL or MariaDB. An SQL export stored alongside the files still needs to be imported into a database during recovery.

Take a page containing an image added in the morning as an example. If the database backed up that evening references it, but the latest media folder is from the day before, the image will be missing after the restore. For your acceptance test, therefore, choose content whose date and associated file you know. Also record a setting change and an authorized fictional account. These markers will let you establish what actually comes back, instead of judging only the appearance of the home page.

Download a verification copy to a private location and check that all expected volumes are present. With split archives, a readable first ZIP does not prove that the series is complete; do not rename the parts at random. Keep encryption passwords and necessary recovery information separately, accessible to the authorized person responsible. If a piece is missing, locate it before preparing a restore: an archive creation message does not make up for its absence.

Guided acceptance test with an UpdraftPlus set on an isolated destination

Prepare a protected WordPress test installation with a separate database and credentials; disable production external connections before its first load. Install the chosen UpdraftPlus edition and check the space available for archives and their extraction. This workflow applies to UpdraftPlus backups: it does not mean that the free version can reimport every format from other products.

In Settings, UpdraftPlus Backups, open Backup / Restore and then Existing backups. Use Upload backup files to send the retained components, or identify the already recognized set. Match its date to the recovery record before selecting Restore. In the wizard, choose the components required for the scenario and read the warnings before confirming. For a full recovery, do not unintentionally leave the database or media outside the scope; for a partial recovery, explain precisely why the other components remain consistent.

The free version also supports a manual move to another address with built-in search and replace; Premium adds direct site-to-site transfer and more selection options, among other features. This is not an invitation to rewrite the live site’s entire database. After the isolated recovery, log back in with the restored accounts and check the displayed address, prepared markers, and media. A URL pointing to production is an acceptance-test failure to correct before continuing.

Keep the log and the start and end times without including any secrets. If the operation fails, record the component and the last error; do not start several restores simultaneously. An insufficient quota requires arranging the missing space with the person responsible for the environment. An access denial requires clarifying the cause with that person, without changing the transport or removing protections to bypass it.

Prepare a Duplicator recovery when WordPress no longer starts

An administration outage changes the choice of workflow. If you have retained a complete Duplicator package, the Classic Install procedure can rebuild a copy without WordPress being preinstalled. Prepare an empty destination directory and an empty dedicated database with authorized access. This scenario targets an isolated rebuild; do not point to the live site’s database simply to check that the installer starts.

Transfer the archive and its matching installer together into this directory, protected by the access measures planned for the acceptance test. Open only the address of that installer at the destination. On the configuration screens, compare the server, database, user, path, and new URL with your record. Understand the validation step before continuing: an option that deletes existing tables would act on the specified database, even if its name resembles that of the copy.

If the proposed information describes an unexpected existing installation, stop. Overwrite mode can replace files and the database, and some pre-existing files absent from the archive may remain. Do not confuse overwriting with a clean rebuild. After a successful test installation, check the report, representative content, and administrator access before considering a return to service.

Then remove the temporary installation files according to the documented cleanup procedure, keeping the emergency archive in its private storage. Verify that the installer’s old URL no longer runs it. To cancel a failed acceptance test, have only the isolated destination returned to its previous state, including its files and database; the source and reference archives remain intact. If that destination has received useful data in the meantime, preserving it takes priority over this rollback.

Calculate the total cost and protect access

The budget may include a license, subscription, remote space, transfers, and support. A free edition does not necessarily include scheduling or the desired connector. Conversely, an old description may become inaccurate if the developer adds features to the free version. The profiles distinguish what was consulted from what still needs confirmation: no missing price has been replaced with an estimate.

An ambiguous currency symbol retains its uncertainty: a price marked only “$” does not automatically become an amount in US dollars. A promotion does not imply a guaranteed renewal price. Before any purchase, check the total including taxes, the billed period, the number of sites, and archive access after cancellation. No purchase was made or account created for this research.

Archives may contain personal data and confidential settings. Protect the account receiving them and limit its permissions to what is necessary. Check that they are not served publicly and that the person responsible for recovery can retrieve access. External storage does not remove the need to check confidentiality, retention, and the effects of account deletion.

Choose a main product family and have the workflow validated

The catalog is not an invitation to install all these plugins. Choose a suitable product family and supplement only identified gaps. A separate job can help a very active database, but several full backups running together complicate monitoring and consume resources. Record the person responsible, schedule, destination, and expected evidence for each job.

On WordPress.com or a managed platform, check the included features and restrictions before adding anything. On multisite, the network administrator must confirm the covered scope and the extent of a restore: support for an ordinary site does not demonstrate support for a subsite. Send precise questions to support, without sending secrets or unsolicited complete archives.

Finally, keep a rollback plan after a test: the location of original copies, emergency access, and the person responsible for deciding whether recovery is acceptable. An existing archive and a job marked successful are useful evidence, but they do not by themselves demonstrate that the site can restart. The isolated test must produce dated findings on your own environment; no universal speed or reliability measurement is attributed to the tools in this article.

Repeat the restore of a page and a file

On a working copy, create a page named “Page témoin” and place a small fictional file in the uploads directory. Record the page text and the file’s SHA-256 hash. Create a database and uploads backup with the same date. Keep both files in the set, their time, and their hashes. Prepare another local installation with a dedicated database.

At the destination, change the marker text and file. Add a page named “Événement fictif récent” to represent data created after the backup. In Settings, open UpdraftPlus and upload both archives from the existing backups section. Verify that both components belong to the same backup. Start restoring the database and uploads to this destination.

In the local acceptance test, the UpdraftPlus 1.26.14 engine restored both archives on WordPress 7.1.4 and MariaDB. In a separate process, WordPress reread the original text and revision 1 of the fictional setting. The recovered file had the same hash as the original. The page created after the backup was absent from the restored destination, and the source’s marker data was unchanged.

The test log reported a MySQL mysqldump client error with MariaDB. UpdraftPlus continued the backup in PHP. During recovery, the account restricted to the target database could not increase the global max_allowed_packet setting. All twelve tables and the marker file were nevertheless restored. On a larger site, check the log and server limits before starting a recovery.

The loss of the recent page shows the effect of rolling the database back. Before a real recovery, record orders, refunds, accounts, or changes received since the backup. A store should reopen only after deciding how to reconcile them with the restored site. The test covers the local engine, database, and uploads. The browser restore interface, themes, plugins, remote storage, and a real payment need their own checks.

• Check the date and hashes of both archives before delivering them to the destination.
• Restore only to the copy. Reload the page and check the file, setting, and recent content.
• Keep a copy of the more recent state until the list of data to recover has been validated.

Further reading

• Recover a deleted WordPress post without restoring the whole site
• WordPress SQL import: resolve “Unknown collation” without altering data
• WordPress images return 404 after migration: repair files and their URLs