If the old server is gone and the new one is still empty, WordPress is not the first thing to bring back.

You need a snapshot that already lives somewhere the failed disk cannot take with it, a dashboard you can still sign in to, and an agent on the new host that can open that snapshot. The new host also needs a database server installed, and the web server already set up, before you start. The restore puts the files back and imports the database into that server. If those pieces are ready, the site should come back up as soon as the restore finishes.

This page is about that move. You restore a snapshot from an offsite location onto an agent you just paired. It is not a matter of uploading a zip and hoping the site comes up. The step-by-step in the docs is [Restore onto a new host](/docs/restore#restore-onto-a-new-host). It takes about five minutes, including the time to pair the agent.

<!-- reaver-youtube:kZzyV6xre5Y | Reaver Backup: restore WordPress onto a new server -->

| Time | What happens |
| --- | --- |
| [0:00](https://www.youtube.com/watch?v=kZzyV6xre5Y&t=0s) | Starting state (old box gone / new box empty) |
| [1:06](https://www.youtube.com/watch?v=kZzyV6xre5Y&t=66s) | Offsite SSH repo already holds the snapshot |
| [1:17](https://www.youtube.com/watch?v=kZzyV6xre5Y&t=77s) | Pair a new agent |
| [2:16](https://www.youtube.com/watch?v=kZzyV6xre5Y&t=136s) | Reassign the site |
| [2:54](https://www.youtube.com/watch?v=kZzyV6xre5Y&t=174s) | Pick snapshot |
| [3:16](https://www.youtube.com/watch?v=kZzyV6xre5Y&t=196s) | Files restore |
| [3:32](https://www.youtube.com/watch?v=kZzyV6xre5Y&t=212s) | Database import |
| [4:37](https://www.youtube.com/watch?v=kZzyV6xre5Y&t=277s) | First successful page. Leftovers: vhost, TLS, DNS, `siteurl` |

- Path on the tape: snapshot-from-offsite (SSH) onto a newly paired agent — not archive upload.
- Restore job on the tape: about **1 min 21 sec** from **Restore snapshot** to the site answering (3:16–4:37).
- Recording length: **5 min 13 sec** (includes pairing the agent).
- Not in Reaver Backup: Nginx/Apache vhost, certificates, DNS.

If the server is still running and only WordPress will not load, you do not need a new machine. Use [Restore when wp-admin is dead](/guides/restore-when-wp-admin-is-dead) instead. That keeps the same agent and the same path, and you restore from the dashboard.

# What has to be true before you start

A new server cannot create a backup you never made.

**The snapshot has to live somewhere other than the disk that failed.** Reaver Backup stores restic repositories where you configured them: on the agent itself, or offsite (S3-compatible storage, Backblaze B2, or SFTP/SSH). A local-only repository, which is what the Free tier uses, is lost if that host is lost. What you can use here is a paid offsite copy, or a portable `.tar.gz` archive you already exported and kept somewhere else. If the only copy was on the server that just failed, there is nothing to restore. That is a missing backup, not something the restore button can fix.

**You still need to be able to sign in to the dashboard.** The control plane is separate from the web server on purpose. If the dashboard was on the same machine that died, rebuild the control plane first. Use the recovery bundle from [Security](/docs/security), which has the master material and the restic passwords. This guide assumes you can sign in, and that the offsite destination credentials are still there.

**The new host needs its own paired agent.** Agents check in with the dashboard. There is no inbound API on the agent. Pair it with New install (SSH) or a manual pairing code, as described in [Agents & sites](/docs/agents). That creates a new agent id. The agent from the old host will not come back online on the new machine.

**The database server has to be installed first.** The restore imports the database into a server that is already running. If nothing is installed to receive it, there is nowhere for that import to go.

**The web server has to be in place first.** Nginx or Apache, and the site config for this host, should already be set up before you restore. Reaver Backup does not install those for you. If the database server and the web server are ready, the site should come back up as soon as the restore finishes.

# The path that matches the docs

The flow in the docs restores a snapshot from offsite onto a newly paired agent. The walkthrough uses SSH. It is not an archive upload.

1. Confirm the offsite repository already has a snapshot you would trust.
2. Pair a new agent on the empty server. Wait until it shows as online.
3. Install the database server, and make sure the web server and site config are already in place.
4. Attach the same offsite destination, then reassign the site onto that agent.
5. Pick the snapshot. Restore writes the files back onto the site path, then imports the database into the server you installed.
6. Watch the job on Restore (Active job) and on Jobs. In the walkthrough, the restore itself takes a little over a minute once you have chosen the snapshot. Pairing takes longer than the restore.

If the database server and the web server were already in place, the site should come back up as soon as that job finishes. Reaver Backup still does not install Nginx or Apache, issue certificates, change DNS, or rewrite `siteurl`. Those need to be ready before the restore, not after. Point the public domain at the new server only after you have confirmed the site is serving. A restore that works by IP address, or through a hosts-file entry on your own computer, is still a success. Changing DNS first only sends visitors to a site that is half moved.

If the job fails right away, the usual causes are an agent that is offline, or a repository the agent cannot unlock because of a password or a destination problem. If the content looks wrong, you probably restored the wrong snapshot, or you restored onto the wrong path on the new host. Check those before you start debugging WordPress itself.

# When you do not have an offsite copy

An offsite repository is the straightforward way to recover a server that is gone. Two other options exist, and each covers fewer situations.

| Situation | What to do |
| --- | --- |
| Old server is gone, and an offsite repository exists | Pair a new agent, attach the same offsite destination, reassign the site, and restore the snapshot |
| Old server is gone, and you already exported an archive and stored it somewhere else | Upload that `.tar.gz` to the dashboard and restore it onto the new agent's site. This is the archive path, not the walkthrough |
| Old server still exists, you are moving, and you have no offsite copy | Export a snapshot to an archive, then restore that package on the target agent |
| Same server, and WordPress will not load | Do not rebuild the host. Use [Restore when wp-admin is dead](/guides/restore-when-wp-admin-is-dead) |

Archive upload has a practical limit. An HTTP 413 means the nginx and PHP upload limits do not match (`client_max_body_size`, `upload_max_filesize`, `post_max_size`). The Archives card shows the chunk size the UI calculated from PHP. If you already have an offsite snapshot, use that instead. You do not have to send the whole site through the browser.

# What "the site is back" does not include

A few things get mixed up while a site is being moved.

Reaver Backup puts the files in the document root and imports the database dump into a database server you already installed. It does not install that database server, install Nginx or Apache, issue certificates, change DNS, or rewrite `siteurl` and `home`. Have the database server and the web server ready first. If the database still points at the old host, the site can keep redirecting there until you update those options. That is normal WordPress behavior, not a failed restore.

It also cannot open a repository it cannot unlock. Local and remote restic passwords are managed in the dashboard, and they belong in the recovery bundle. Keep that bundle somewhere offline before you need this page.

A full-machine snapshot from your VPS provider is a different layer. It can bring the whole server back, including files you did not mean to keep. This guide is about the site itself: the files and the database, on a server you have already prepared. The longer comparison is in [plugin backups vs server-level backups](/guides/plugin-vs-server-backup).

# Who this is for

**A good fit**

- The web server is down, or you are moving on purpose, and a restic snapshot already lives somewhere other than that disk.
- You can still reach the dashboard, or you can rebuild it from the recovery bundle.
- You can install the database server and set up the web server before the restore, then handle TLS and DNS if they are not already pointing at this host.

**Not the right fit**

- You have no offsite copy and no exported archive stored anywhere else. There is no snapshot to restore.
- You are on shared hosting without SSH, so you cannot pair an agent. Use the plugin's own restore, or FTP plus a database dump.
- WordPress is down, but the same server and the same agent are fine. Stay with the same-server restore.

# Related reading

- [Restore when wp-admin is dead](/guides/restore-when-wp-admin-is-dead). Same server, a white screen, and no new host.
- [Restic WordPress backups without glue scripts](/guides/restic-wordpress-backup). How the snapshot got off the server in the first place.
- [Many WordPress sites, one dashboard](/guides/many-wordpress-sites-one-dashboard). One agent per server, once you are protecting more than this site.
- Operator detail: [Restore & archives](/docs/restore), [Agents & sites](/docs/agents), [Offsite setup](/docs/offsite-setup).

# Next step

If the offsite snapshot is already there, pair the new agent and follow [Restore onto a new host](/docs/restore#restore-onto-a-new-host). If it is not, set that up before the next failure. A local-only copy will not survive a disk that dies. Offsite destinations are on [Cloud destinations](/docs/cloud-destinations).

# Short answers

**How do I restore WordPress onto a new server with Reaver Backup?**
Install the database server and set up the web server on the new host, pair a new agent, attach the same offsite destination, reassign the site, and restore a restic snapshot. The files come back first, then the database is imported into the server you installed. If those pieces are ready, the site should come back up as soon as the restore finishes.

**Can I restore if the only copy was on the dead server's disk?**
No. A local-only restic repository is lost with that disk. You need an offsite snapshot, or a portable archive you already stored somewhere else.

**Does Reaver Backup set up the vhost, TLS, and DNS?**
No. Put the web server in place before you restore, along with the database server. Reaver Backup puts the files back and imports the database. It does not install Nginx or Apache, issue certificates, or change DNS.

**What is the difference between this and restoring when wp-admin is dead?**
If wp-admin is down on a server that is still running, you use the existing agent and restore over that site path. A new server means a new agent, and a snapshot that was not stored only on the old disk.

**What if I do not have an offsite restic repo?**
If the old server is still available, export an archive and restore that package on the new agent. If the old server is already gone and you never copied an archive off it, there is nothing to restore.