Docs · Guides
Where should your backups live? Local disk, S3, B2, or SSH
Keep one backup on the same server for speed, and one copy somewhere else so a lost server does not take your backups with it. Reaver Backup sends that second copy to storage you control, whether you protect a WordPress site, an app, or a directory.
Keep one backup on the same server and one copy somewhere else. The copy on the server is quick and handy, and the copy elsewhere is the one that saves you when the server is gone.
The disk your site or app runs on is the worst place to keep your only backup. If that disk fails, or the server is deleted or hacked, the data and its backup go together.
This applies to whatever you protect. Reaver Backup can back up any directory that the user running Reaver Backup has access to, and it can find WordPress sites on its own. WordPress is a common example, and we use it below, but the same advice holds for any site, app, or folder.
Why a backup on the same disk fails with the server
A local backup protects you from small mistakes. You delete a file, an update breaks a page, and you roll back in a minute or two. It is fast because nothing has to cross the internet.
But a lot of real failures take out the whole machine: a failed disk, a deleted server, a hosting account that is closed, or an attacker who gets in and removes what they can find. In each case, a backup stored next to the data is gone too. You then have nothing to restore from.
So think of two jobs. Local storage is a fast first copy for everyday fixes. A copy on different storage is what you need for disaster recovery.
Your options
Reaver Backup supports local storage on the agent's disk, plus three offsite types: S3-compatible storage, Backblaze B2, and SFTP over SSH.
| Local disk | S3-compatible | Backblaze B2 | SSH (SFTP) | |
|---|---|---|---|---|
| Cost | No extra cost; it uses space on your server | Pay the storage provider; prices differ by provider, so check theirs | Pay Backblaze; check their pricing page | Free if you already have a server with space; otherwise the cost of that server |
| Speed | Fastest, no network | Depends on your connection and the region you pick | Depends on your connection and the region you pick | Depends on the network between the two machines |
| Setup effort | None | Medium: an access key, secret, bucket, and sometimes an endpoint | Medium: a key ID, application key, and bucket | Medium: a host, user, path, and an SSH key (Reaver Backup can create and install one) |
| Who controls it | You, but it shares the fate of the server | You hold the bucket and keys; the provider runs the hardware | You hold the bucket and keys; Backblaze runs the hardware | You, fully, including the hardware |
| Survives the server dying? | No | Yes | Yes | Yes, if it is a different machine |
According to the Reaver Backup docs, "S3-compatible" covers AWS S3, Wasabi, DigitalOcean Spaces, MinIO, and other services that use the S3 API. We have not listed provider prices here because they change. Check the provider's own pricing page before you choose.
A simple recommendation by situation
You run one site or app. Keep the local backup, and add one offsite destination. Pick the one you find easiest to set up: a bucket on S3 or B2 if you want someone else to run the hardware, or SSH to a second machine if you have one.
You manage sites for clients (an agency). Keep a local copy on each server for quick fixes. Send everything offsite as well, to a bucket you own. A client's server can fail on any day, and a copy that does not depend on that server is what you will need then. Using one account for storage also keeps costs and access in one place.
You run your own server or homelab. If you have a second machine in another room, another building, or another provider, SSH to it can be a good offsite copy at no extra service fee. The key point is that it must be a different machine from the one holding the data. If it is the same box or the same power and disk, it is not offsite.
In every case, the same idea holds: two copies, on different storage. After you set it up, run a test restore. Our guide on restoring WordPress to a new server shows how the offsite copy is used.
What the Free tier includes
Plainly: the Free tier is local storage only. It covers one site (any path), with incremental backups and cron scheduling, but no offsite destination. That is fine for trying Reaver Backup, but it means your backups stay on the same server as your data.
Per the pricing page, Solo and Starter include one offsite destination, and Pro, Agency, and Scale include unlimited offsite destinations. Check that page for current plans and limits.
How to attach a destination in Reaver Backup
These steps follow the Cloud destinations and Offsite storage & SSH setup docs. Read those for the full detail.
- Open the Off-Site page in the dashboard and add a destination.
- Choose the type: S3-compatible, Backblaze B2, or SFTP / SSH.
- S3-compatible: enter the access key, secret, endpoint (a host or IP; leave it blank for AWS), region, bucket, and an optional prefix.
- Backblaze B2: enter the key ID, application key, bucket, and an optional prefix.
- SFTP / SSH: enter the host, port, user, and remote path. Reaver Backup uses key login only; password-only SSH does not work with restic's SFTP backend. If you leave the private key blank, Reaver Backup can generate a key and install it on the remote host for you, using a password or an existing key for that one-time step.
- Save the destination, then click Test. If the test fails, fix that before you go on.
- Attach the destination to a schedule, or set it as the site's primary repository, or both.
- Queue a backup from the Dashboard or wait for the schedule, then check the Jobs page to confirm it succeeded.
This works for any directory the user running Reaver Backup can access, not only WordPress. Each site or path gets its own restic repository under your optional prefix, in the form {prefix}/{site-slug}.
One more thing the docs point out: client-side restic encryption is optional and off by default. If you leave it off, rely on your provider's server-side encryption or on disk encryption on your own SSH target. Credentials stored in the dashboard are always encrypted.
Backups go to storage you control
Reaver Backup does not run a storage service for your files. The destination is your bucket or your server, and you choose who can reach it. That is also why it is worth taking a little time to choose well.
Related reading
- Restore WordPress to a new server. A worked example of using the offsite copy when the server is gone.
- Restic WordPress backups without glue scripts. How the backups are made and how they reach another place.
- Restore when wp-admin is dead. For when the server is fine but the site is not.
- Operator detail: Agents & sites, Cloud destinations, Offsite storage & SSH setup.
Next step
Open the Off-Site page and add a destination by following Offsite storage & SSH setup. If you only need the list of supported types, see Cloud destinations.
A backup that lives only on the server it protects is lost when that server is lost.
Short answers
Where should I store my backups?
Keep one copy on the same server for speed, and one on different storage, such as S3-compatible storage, Backblaze B2, or another machine over SSH. The offsite copy is the one that survives if the server is lost.
What can Reaver Backup back up?
Any directory that the user running Reaver Backup has access to. WordPress sites can be found automatically, and other directories you point it at get the same schedules and destinations.
Is a backup on the same server enough?
No. It helps with small mistakes, but if the disk fails or the server is deleted, the backup is lost with the data.
Can I use the Free tier for offsite backups?
No. The Free tier is local storage only. Offsite destinations start on the Solo and Starter plans, which include one, and Pro, Agency, and Scale include unlimited. See the pricing page for current details.
Which offsite option should I choose?
Choose the one you can set up and keep running most easily. S3-compatible storage and Backblaze B2 are run by a provider, and SSH works well if you have a second machine somewhere else. What matters most is that the copy lives on different storage from the original.
Who can read my backups?
You decide, because the destination is your own bucket or server. Optional client-side encryption is off by default, so turn it on if you want it, or rely on your provider's server-side encryption or your own disk encryption. Credentials stored in the dashboard are always encrypted.