Docs · Guides
Plugin backups vs server-level backups for WordPress
A plugin, a host snapshot, and a server agent are not the same kind of backup. Here is how they differ when WordPress itself will not load.
The backup you thought you had often fails on the same morning the site does.
WordPress whitescreens. You cannot reach wp-admin. The plugin that was supposed to restore everything is part of that same broken install. Maybe there is a zip in Google Drive. That does not help much if the only restore button you know lives inside the site that just died.
That story is common, and it is not an argument for throwing plugins away. Plugins are fine for a lot of sites. The problem is treating every “backup” as the same thing. A plugin, a host snapshot, and a backup that runs on the server are three different layers. They fail in different ways, and they recover in different ways. Once you can see the layers, the rest of the choice gets easier.
The three layers
Think of it as where the work actually happens.
| Layer | Where it runs | Works if wp-admin is dead? | You control offsite + restore? | Best for |
|---|---|---|---|---|
| Backup plugin | Inside WordPress (PHP, WP-Cron, the plugin screen) | Usually no | You can send files offsite; restore often still needs WordPress to boot | One site, shared hosting, no SSH |
| Host / panel snapshot | The host’s disk or control panel | Yes, as long as the host is up | Often no. You wait on their panel or their ticket | Fast rollback on a managed host |
| Server agent + dashboard | On the machine, not inside WordPress | Yes | Yes, if you choose the destination | VPS, dedicated, homelab, more than one site |
You can use more than one layer. Plenty of people should. The expensive mistake is assuming a plugin is doing the job of a server-level backup.
Layer 1 — Plugins (UpdraftPlus and friends)
If you are on shared hosting and you cannot SSH into the box, a WordPress backup plugin is still the sensible default. You install it, point it at Drive, S3, or Dropbox, set a schedule, and restore from wp-admin when a theme update goes wrong. For a single brochure site, that loop is familiar and it is often enough.
The limits are built into where it runs. The plugin is PHP, so it lives with the same memory cap, timeout, and cron behavior as the rest of WordPress. A job that never finished can still leave you thinking you “have backups,” because the plugin is installed. And when restore itself runs in the WordPress dashboard, WordPress has to boot first. A fatal error, malware in wp-content, or a database that will not start can take that dashboard with it.
There is also the fleet problem. One plugin on one site is easy. Ten client sites means ten plugins, ten crons, and ten places to miss a failed job.
So stay with a plugin when you cannot install anything on the server, and when you can live with a slower recovery: FTP the files up, import the SQL dump, and piece the site back together by hand.
Layer 2 — Host snapshots
Most hosts offer something that looks like a backup. It might be a cPanel download, a daily snapshot on a managed WordPress plan, or a disk image of the VPS. Those copies are useful. They are also easy to over-trust.
The snapshot usually sits with the same company that runs the site. If that account or that provider is the problem, the copy may not help you. Restore is whatever their panel or their ticket queue allows, on their timeline. You rarely get a clean “these files and this database, as of 2 a.m., sitting in a bucket I own.” Retention is whatever the plan includes, not a policy you designed.
Treat host snapshots as a fast undo on that machine. They are a good extra layer. They should not be the only copy you would bet a client site on.
Layer 3 — Server-level backup with a dashboard
This is the layer people reinvent with cron, mysqldump, and restic — and then quietly stop maintaining six months later.
The work itself is not mysterious. The backup has to run on the server, whether WordPress is healthy or not. It should find the site the way Nginx or Apache already does, from server_name and root. For WordPress it should read wp-config.php, dump the database, and store that dump with the files. The repository belongs on storage you chose: local disk for a first test, or S3, Backblaze B2, or SSH when you care about disaster recovery. And the restore screen cannot live in wp-admin. If it does, you are back in layer 1.
Reaver is that loop without the pile of scripts. The dashboard sits outside WordPress, under /var/www/reaver/, any directory the web user can serve, or a completely different machine. A small agent on each web server polls the dashboard — nothing inbound on the agent — finds WordPress installs (or any folder you point at), and runs the backup. Schedules, retention, mail, and restore all live in that one UI.
Storage stays yours. Reaver is not a vault that holds your site files for you. Encryption at rest on S3 or B2 is already the provider’s default. Optional client-side restic encryption exists if you want another layer; it is off by default, and if you turn it on and lose the key, that data is gone. We make you acknowledge that because it is true, not because it sounds careful.
What “the site was down” actually means
“Down” covers a few different mornings. The right layer depends on which one you are in.
| What broke | Plugin restore | Host snapshot | Server agent |
|---|---|---|---|
| Bad plugin or theme update, but wp-admin still loads | Often fine | Fine | Fine |
| White screen, or wp-admin fatals | You are on FTP and phpMyAdmin | Panel rollback, if they have one | Restore from the dashboard onto the docroot |
| Database dropped or corrupted | The plugin UI may be down with it | Only if their snapshot includes the database | Restore the dump and the files from the snapshot |
| Malware in WordPress files | The plugin may be infected too | Depends on when they snapped | Restore an older snapshot from offsite |
| The whole VM is gone | An offsite zip helps only if you can rebuild by hand | Gone, if the snapshot lived on that host | The offsite restic repo on S3, B2, or SSH is the way back |
One more distinction that's easy to miss. A plugin archive sitting on the same disk as the site is not an offsite backup. If the machine dies, that zip dies with it.
Who should stay where
If you are on shared hosting with no SSH, you have one small site, and a few hours of manual recovery would not sink you, stay on a plugin. That's the honest fit.
If you are going to rely on host snapshots alone, read their restore time and retention the way you would explain them to a client. Then test a restore. A “backup completed” email is not the same thing.
Add a server-level backup when you can install an agent (or already have SSH), when more than one site lives on the box, or when the site is something you cannot rebuild from memory — a store, a lead machine, a client you would have to call. It also pays off when you are tired of opening every wp-admin just to ask whether last night's backup ran.
Reaver is the wrong tool if you want no servers at all and a company that keeps the files for you. That is a managed vault. Different product. Better to say that before anyone installs anything.
What the day-to-day looks like
Once the dashboard is in place and the agent is on the web host, the loop is short. Sites show up. You pick where the backups go. You run one by hand so you know it works. You set a schedule. After that you watch the status board or the mail, and you restore from the same screen when something breaks.
On a Linux box the first backup is usually about fifteen minutes: install the dashboard, pair an agent, let WordPress appear, use local storage to prove the pipeline, then add offsite before you trust it. Local is how you learn the tool. Offsite is how you survive the host dying.
The click-by-click version lives in the docs, not here: First backup and Restore.
Short answers
Is a WordPress backup plugin enough?
For one small site on a host you cannot control, yes — after you have actually restored from it, and after a copy lives off that server.
Why did the plugin backup fail when the site was down?
Because the restore path was the same WordPress install that just died.
Are host backups enough?
They are a good second copy on that host. They are not the same as a destination you own.
Do I need restic, or a dashboard like Reaver?
You need something that runs outside WordPress and keeps history off the machine. A dashboard you will still open next year is one way. A script you will still understand next year is another. Most people do not keep maintaining the script.