EffortLess Backup And Restore

Directly inside wp-content/ , in a folder with a randomly generated name, protected by a .htaccess rule that denies all direct web access on servers that honor it. Backups are never linked to directly from the admin page — downloading one always goes through a password-protected (nonce and login) handler.

The entire database (every table, not just WordPress’s own — any custom tables from other plugins are included), and the entire wp-content directory (themes, plugins, uploads, and anything else placed there), excluding this plugin’s own backup storage folder.

The database is dumped table by table, not as a single all-or-nothing snapshot — on a very active site, a write landing in one table right as its neighbor was already dumped (for example, a new post saved between the wp_posts and wp_postmeta tables being dumped) could in principle leave a backup with the two very slightly out of step. This is normal for a lightweight, dependency-free backup tool and not something to worry about on an ordinary site.

The files backup is extracted back over wp-content , overwriting the current files, and the database dump is replayed, replacing every table’s structure and data with what was captured at backup time. This is a significant, hard-to-partially-undo action — a fresh backup of your site’s current state is taken automatically right before a restore begins (unless the most recent backup is only a few minutes old already, in which case that one serves the same purpose), so you can restore back to “just before this restore” if needed. If that safety backup itself can’t be taken (for example, the disk is full), the restore is aborted before touching anything, rather than proceeding with no way back.

Only one backup or restore can run at a time — the Backups page shows a notice and disables “Backup Now” and “Restore” while one is in progress, and automatically re-enables them (refreshing the page) once it finishes.

A restore runs in the background in small steps rather than one single request, so it can complete even on a host that limits how long a request may run — the Backups page shows its progress and updates on its own when it finishes; there is no need to keep a browser tab open or stay logged in for it to continue. It isn’t wrapped in one all-or-nothing database transaction (structural changes like CREATE TABLE commit immediately in MySQL regardless of any transaction). While a restore is running, the site’s public pages (and REST API) show a brief “back shortly” message instead of staying live — this prevents a visitor’s activity (an order, a comment, a form) from being silently lost when the restore replaces the database moments later. If the backup file being restored turns out to be truncated or corrupted, the restore stops with a clear error instead of silently skipping the missing part.

No. Restoring extracts the backup’s files archive back over wp-content , which overwrites any file the backup contains and adds back any file it deleted — but a file created after the backup (for example, a new plugin installed since then) is left in place, since it simply isn’t part of what’s being restored. The database is fully replaced either way, so a plugin added after the backup point would show as installed on disk but not activated in the (restored) database.

The files archive and database dump can both be downloaded from the Backups page. Restoring on a different WordPress install isn’t a built-in one-click feature in this version — this plugin is built for keeping (and restoring) a site’s own recent history, not general-purpose site migration.

Yes, and it always covers the whole network at once — a Multisite network’s sites all share one database (so the database dump already includes every site’s tables, not just one) and one wp-content directory, so there is no meaningful way to back up or restore “just one site” separately from the rest.

Because of that, this plugin must be Network Activated , never activated on an individual site. Network Activating moves its admin page to Network Admin → Backups, and requires a Super Admin ( manage_network_options ) rather than an ordinary site Administrator — restoring here overwrites every site on the network, which a single site’s own Administrator must never be able to trigger. If it’s ever activated on just one site by mistake, a notice on that site explains this and points you to Network Activate it properly instead; it doesn’t do anything from that per-site activation.

WordPress’s scheduler (WP-Cron) only runs when a page on your site is visited, so a very low-traffic site can take a little over a day for its first automatic backup to appear — click Backup Now in the meantime for an immediate one. Also confirm your host has the PHP zip extension enabled; without it, the Backups page shows a notice and the files portion of any backup will fail.