Restic WordPress backups without glue scripts

You already know the honest WordPress backup loop.

Dump the database. Capture the files. Push both somewhere that is not the same disk that just died. Keep enough snapshots that last Tuesday still exists. Forget the ones you no longer need. Do it again tomorrow.

Restic is excellent at the middle of that story: incremental snapshots, deduplication, and destinations you choose. The glue is what wears people down. A shell script here, a cron line there, a mysqldump wrapper that broke after the last MariaDB upgrade, a forget policy you meant to tighten six months ago. Multiply that by a handful of sites and you are maintaining a backup product in your spare time.

This guide is for operators who like restic and do not want to keep that glue forever. Reaver Backup still uses restic under the hood. What changes is who owns discovery, schedules, retention, status, and restore: a dashboard you host, plus a poll-only agent on each web server.

If you only have one brochure site on shared hosting with no SSH, stay on a plugin. The longer “when to stay” argument is in plugin backups vs server-level backups. If your pain is forty wp-admins instead of scripts, start with Many WordPress sites, one dashboard.

What the glue usually looks like

A typical DIY restic WordPress setup ends up looking like this, even when it started “simple”:

1. Find every docroot (sites-enabled, wp-config.php, or a handwritten list).
2. Dump MySQL or MariaDB with credentials scraped from wp-config.php or a secrets file.
3. restic backup the files plus the dump into a repo on disk, S3, B2, or SFTP.
4. restic forget / prune with a retention policy you hope still matches reality.
5. Cron the whole thing, plus mail or a webhook when it fails.
6. On restore day, remember which snapshot id was good, unlock the repo, put files back, import the dump, and hope you documented the path.

None of that is wrong. It is just a second product. Scripts drift. Sites move. The person who wrote the first version leaves. The night something fails is usually not the night you want to debug shell quoting.

What Reaver Backup keeps and what it replaces

Reaver Backup does not invent a new backup format. The agent on the host runs restic. Snapshots are restic snapshots. Destinations are restic repositories you configure — local on the agent, or offsite to S3-compatible storage, Backblaze B2, or SFTP/SSH (keys only for restic SFTP).

What the dashboard takes over:

You still choose where bytes live. Reaver Backup is not a vendor vault for your site files. Free keeps repositories local on the agent. Paid plans unlock offsite destinations. Agents are unlimited; your plan limits sites (managed restic repositories, WordPress or custom path).

One honest leftover: the dashboard still needs a minute runner so schedules fire (cli/run_schedules.php via the Schedules page’s automatic scheduling). That is one system cron for the control plane — not a growing pile of per-site dump scripts. Details live under Schedules.

Restic under the hood (without the CLI homework)

On each protected host, the agent polls the dashboard, claims jobs, and runs restic. There is no inbound HTTP API on the agent. Incremental, deduplicated snapshots are the default story. Optional client-side restic encryption is off by default; when you enable it, local and remote restic passwords are dashboard-managed and belong in the Security recovery bundle. Enabling encryption requires the product’s liability waiver — read Security before you flip it.

Passwords are not meant to live in shell history. The operational model is dashboard-held credentials, short-lived materialisation for restic on the agent, then cleanup. If you lose the dashboard secrets and the recovery bundle, you have the same class of problem every encrypted restic operator has: protect the recovery material offline.

Reaver Backup manages the repositories it creates for sites. Do not expect a one-click “attach my ten-year-old hand-rolled restic repo and inherit its history” path. History in Reaver starts when the first snapshot lands in a repo the product manages. Keep an old DIY repo around for archaeology if you need it; run new protection through the dashboard.

A sane first path (minutes, not a weekend of scripting)

Order matters, and it matches the in-product walkthrough:

1. Install the dashboard on a Linux box you control — Installation.
2. Pair an agent on the web server (Agents & sites). Prefer Upgrade (SSH) when an agent already exists so identity stays intact.
3. Let discovery find site configs, or add a custom path (optional MySQL/SQLite dump) when the site is not WP.
4. Choose storage: local for a smoke test, or configure offsite (S3 / B2 / SFTP) and Test it — Cloud destinations, Offsite setup.
5. Run one backup by hand. Confirm a completed job and a snapshot you could restore.
6. Add a schedule and retention. Enable automatic scheduling on the Schedules page so the minute job actually runs.
7. On a calm day, practice a restore — even onto a scratch path — so restore day is not the first time you trust the dump and the files together.

That is the same dump + files + forget loop you already believed in. The difference is you are not maintaining it as a private shell library.

Who this is for (and who should skip it)

Good fit

• You already like restic, or you want restic without babysitting cron and forget policies.
• You have SSH on Linux hosts and care where snapshots live (disk you control, B2, S3-compatible, SFTP).
• You want restore that does not depend on WordPress booting.
• You grow past one site and do not want N scripts to keep pace.

Wrong tool for this week

• Shared hosting with only wp-admin and FTP — stay on a plugin for now.
• You need Reaver Backup to ingest and continue an existing DIY restic repository’s history as-is — keep that repo; start new managed repos for ongoing protection. (connecting existing repos is coming soon)
• You want a hosted SaaS vault that holds every customer’s files by default — that is a different product category.

Related reading

• Plugin backups vs server-level backups — three layers: plugin, host snapshot, server agent.
• Coming from UpdraftPlus, BlogVault, or BackupBuddy — same job, different control plane.
• Many WordPress sites, one dashboard — fleet shape and site packs.
• Restore when wp-admin is dead — white screen morning without the plugin restore button.
• Operator manual: First backup, Backup jobs, Schedules, Restore.

Short answers

Does Reaver Backup use restic? Yes. Restic is the backup engine on the agent. Reaver Backup manages repositories, snapshots, schedules, jobs, and restore through the dashboard.

Do I still need my own cron scripts for WordPress dumps and restic forget? Not for the per-site dump/backup/forget loop. Schedules and retention live in the UI. You do still enable the dashboard’s minute scheduling job so those schedules fire.

Can I point Reaver Backup at an existing restic repository I already manage by hand? No assumed import of DIY repo history. Reaver manages the repos it creates for sites. Keep old repos for reference if you need them; run ongoing protection through managed sites. (connecting existing repos is coming soon)

Is client-side restic encryption required? No. It is optional and off by default. When enabled, passwords are dashboard-managed and belong in the Security recovery bundle; enabling it requires the product waiver.

Where do WordPress backups go — local disk, B2, or S3? Wherever you configure: local on the agent (Free), or offsite S3-compatible, Backblaze B2, or SFTP/SSH on paid tiers. Not a Reaver-hosted vault for site files.

Next step

If the DIY restic loop still works but the glue is the tax, stand up the dashboard once, pair one agent, and take a single snapshot you can restore. The click path is First backup. Pricing for offsite and site packs is on Pricing.