Docs · Guides

Back Up Any Website, App, or Database You Host Yourself

Reaver Backup is not only for WordPress. Add an app's folder as a custom path, put its MySQL or MariaDB dump in the same snapshot, and send that snapshot to S3, Backblaze B2, or another machine over SSH.

Most self-hosted setups are not one WordPress site. They are a static site in one folder, a small web app in another, a wiki or forum somewhere else, and a database or two that everything leans on. Each one tends to get its own backup script, and each script fails quietly in its own way.

This guide covers the part of Reaver Backup that has nothing to do with WordPress: custom path backups. WordPress sites are found automatically. Everything else is a path you add, and it gets the same schedules, destinations, retention, and restore tools.

What a custom path can be

A custom path is a folder on a server that runs a Reaver Backup agent. The agent runs as the web user (www-data by default) unless the admin picks a different user at install, so it can back up folders that user can read. Restores write back to the same folder, so that user needs write access there too.

The path also has to look like a site directory. These are the current rules:

It must be absolute and sit under a web root: /var/www/…, /srv/www/…, /srv/http/…, /usr/share/nginx/…, /var/lib/caddy/…, or /opt/bitnami/…. Folders inside a user's home also work, such as /home/<user>/public_html/… or /home/<user>/sites/app.
It must be at least three levels deep. /var/www/example.com works. /var/www on its own does not.
Broad top-level paths are refused, such as /, /root, /home, /var, /srv, /opt, /usr, /tmp, and /etc. Nothing under /root is allowed, and .. is not accepted.

Full details are in Agents & sites. Admins who run Reaver Backup as a different user can reach folders the web user cannot read, but the path rules above still apply.

Good candidates are sites that are not WordPress (a static site or another CMS), self-hosted web apps whose code and uploads live under a web root, and several sites on one server, each added as its own path.

Each custom path counts as one site on your plan, the same as a discovered WordPress site. Agents are unlimited. See Pricing for the site limits.

Files are only half of it: add the database

Copying the folder a database lives in while the database is running is a poor backup. The files can be caught halfway through a write, and the copy may not open later. A dump is the safe way to capture a running database, and Reaver Backup can take one for you.

MySQL and MariaDB are the built-in path, because that is what most websites run on.

Database	What Reaver Backup does
MySQL / MariaDB	Optional dump with `mysqldump` or `mariadb-dump` on the agent. You enter the host, port, database, user, and password. The dump is saved in the same restic snapshot as the files, and a restore imports it back into the database.
SQLite	Files inside the path are already backed up. If the database file lives outside the path, add its absolute path and Reaver Backup saves a copy of the whole file in the same snapshot. A restore copies it back to the same path.
PostgreSQL	Not built in. Schedule your own `pg_dump` into a folder inside the path, a little before the Reaver Backup schedule, and the dump is backed up with the files. Keep that folder out of what your web server serves.

The database credentials you enter are stored encrypted on the dashboard. The dump tool has to be installed on the agent host and able to reach the database at the host and port you give it.

For SQLite, the safest copy is one taken while the app is not writing, so schedule backups for a quiet time.

Getting it off the server: S3 or B2

A backup on the same disk goes down with that disk. The full reasoning is in Where should your backups live?. The short version is to keep a local copy for quick fixes and send a second copy somewhere else.

Reaver Backup supports three offsite types, and they work the same way for a custom path as for a WordPress site:

S3-compatible storage: AWS S3, Wasabi, DigitalOcean Spaces, MinIO, and other services that use the S3 API. The database dump and the site folder go up as one snapshot.
Backblaze B2: a key ID, an application key, and a bucket.
SFTP over SSH: another machine you control, with key login.

Under the hood, Reaver Backup uses restic, with one repository per path ({prefix}/{site-slug}). Backups are incremental and deduplicated, so a large folder that changes a little each day does not cost a full copy each night.

The Free tier is local storage only. Offsite destinations start on Solo and Starter, which include one, and Pro, Agency, and Scale include unlimited. Check the pricing page for current details.

How to set up a custom path

These steps follow Agents & sites, Schedules, and Cloud destinations. Read those for the full detail.

Pair an agent on the server that holds the data. The steps are in First backup.
On the Agents page, open Custom path backup. Choose the agent, give the backup a display name, and enter the absolute path.
If the app uses MySQL or MariaDB, turn on the dump and enter the connection details. If it uses a SQLite file outside the path, add that file's path.
Add an offsite destination on the Off-Site page and click Test. Fix any failure before you go on.
On the Schedules page, create a schedule for the path: pick the destination, the frequency (hourly, daily, weekly, or monthly), and how many snapshots to keep. One path can have several schedules, such as daily local and weekly offsite.
Click Run now, then check the Jobs page to confirm the backup succeeded.

Schedules only fire if the dashboard's minute job is running. Use Enable automatic scheduling on the Schedules page if you have not done so already.

Restoring a directory or database

Restore works the same way for a custom path as for a WordPress site. On the Restore page, pick the path and a snapshot, then answer four questions:

What should come back? Files and the database, files only, or the database only.
Which files? Everything in the snapshot, or only the files and folders you tick in the snapshot's file list.
Where should they go? Back onto the live path, into a different folder on the same server (it follows the same path rules), or into a private folder outside the web root so you can look first.
What about files already there? Replace matching files and leave the rest, which is the usual choice. Or make the folder match the backup exactly. Files that are not in the backup are moved out of the folder and shown in a preview before anything changes. They are deleted once the restore is checked, unless you choose to keep them for a few days. That works only when you restore every file.

With the database included, the MySQL or MariaDB dump is imported into the database you set up for the path. For a database-only restore you can import into a different database instead, without changing the path's saved settings. A SQLite file is just a file, so there is nothing to import: one inside the path comes back with the files, and one outside it is copied back to the path it had when the backup ran, with its owner and permissions. Stop the app that uses it first.

Before importing, Reaver Backup saves a copy of the database that is there now. If the import fails, that copy puts the old database back. After a successful, checked restore it is deleted, unless you keep it. If the disk is too full for that copy, the restore says so and goes ahead without one.

A PostgreSQL dump you scheduled yourself comes back as a file in the path. Load it the same way you would load any pg_dump file. The full steps are in Restore.

If the server itself is gone, pair a new agent on the new machine, attach the same offsite destination, and restore from there. Restore WordPress to a new server walks through that path. The WordPress parts do not apply, but the order does: install the web server and the database server first, then restore.

What Reaver Backup does not do here

It does not install or configure your app. It puts files and data back. The app, its runtime, and the database server have to be there first.
It does not dump every kind of database. MySQL and MariaDB dumps are built in, and SQLite files are copied. Anything else needs its own dump into the path.
It does not read folders its user cannot read. That is www-data unless the admin chose another user. If a backup fails on permissions, check that user's access first.
It does not find non-WordPress apps on its own. Discovery is for WordPress. Everything else is a custom path you add.

Who this is for

Self-hosters with more than WordPress. You run a few sites and web apps on your own server and want one place to see what was backed up last night, instead of a cron job per app.

Developers and small teams with their own apps. A web app with a MySQL database and an uploads folder is one custom path with the dump turned on.

Mixed fleets. WordPress sites and other sites on the same servers live in one dashboard, under the same plan limits.

Where should your backups live?. Local disk, S3, B2, or SSH, and how to choose.
Restore WordPress to a new server. The new-machine restore order, which applies to any site.
Restic WordPress backups without glue scripts. What replaces the dump-and-forget scripts.
Many WordPress sites, one dashboard. For fleets that mix WordPress with other paths.
Operator detail: Agents & sites, Schedules, Cloud destinations, Restore.

Next step

Pick the one site or app you would least like to lose. Add its folder as a custom path, turn on the database dump if it has one, and attach an offsite destination. Then restore a snapshot into a private folder to check that it is all there.

A backup you have restored once is worth more than ten you have only scheduled.

Short answers

Can Reaver Backup back up directories that are not WordPress?

Yes. Add a folder as a custom path, and it gets the same schedules, destinations, and restore tools as a WordPress site. The folder has to be readable by the user Reaver Backup runs as (www-data by default) and follow the web-root path rules.

Can it back up a MySQL or MariaDB database?

Yes. Turn on the dump for the custom path and enter the connection details. The agent runs mysqldump or mariadb-dump and saves the dump in the same snapshot as the files. A restore with the database included imports it back.

What about PostgreSQL?

There is no built-in PostgreSQL dump. Schedule pg_dump to write into a folder inside the custom path, and Reaver Backup backs up the dump with the files.

Can I back up a directory to Backblaze B2 or S3?

Yes, on paid plans. Add a Backblaze B2 or S3-compatible destination on the Off-Site page, test it, and attach it to the path's schedule. The Free tier is local storage only.

Can I restore just one file or folder?

Yes. Tick the files and folders you want in the snapshot's file list. They can go back onto the live path, into another folder, or into a private folder to inspect first.

Can I back up any folder on the server?

No. Custom paths must be under a web root, at least three levels deep, and readable by the user Reaver Backup runs as. Broad paths such as /, /root, /var, and /opt are refused.