Restore when wp-admin is dead

You cannot open wp-admin. The screen is white, or it fatals halfway down, or the login form posts you back to the same error. The restore button you have used for years lives inside that same WordPress install. That is the morning this page is about.

The server itself is still there. SSH still works, or the host panel still works, or the Reaver Backup dashboard — which does not live in WordPress — still loads. What you need is a snapshot the agent can still unlock — local or offsite. Where the repo lives does not matter if it reads.

If the whole virtual machine is gone, stop here and go to restore onto a new host. That is a different recovery. This guide stays on the box that is still answering.

What "wp-admin is dead" usually means

Most lockouts are one of a few familiar failures, and they are worth separating because the leftovers after restore are not the same.

A plugin or theme update can take PHP down with it. You get a white screen or a fatal that names a file in wp-content. The site path is fine. MySQL is fine. WordPress just will not boot far enough to show you the plugin screen.

Malware in wp-content is uglier because the restore UI may be infected too. You want a snapshot from before the compromise that the agent can still read — and that the malware did not rewrite. A plugin zip that lived inside the infected tree is a poor bet.

The database can be dropped, corrupted, or left in a state where wp-admin cannot talk to it. Files on disk may look healthy. Without the matching dump, they are a theme museum.

Sometimes the front of the site still renders and only the admin routes are broken — a bad .htaccess, a hijacked login, a redirect loop. The server is up, but WordPress as an application is not a safe place to click Restore.

Why the plugin UI often cannot save you

Backup plugins earn their keep when WordPress still boots. Restore is a PHP job inside the same app that just died. If a fatal in wp-content is what took the dashboard away, asking that dashboard to put the files back is asking the problem to fix itself.

There is a second, quieter failure that shows up on the same morning. The backup you thought you had may never have finished. Plugin jobs share the host's memory cap, timeout, and WP-Cron. A partial archive in Drive can look like protection until you need the whole site.

The longer argument — plugin vs host snapshot vs server agent — is already written. This page does not reteach it. Read plugin backups vs server-level backups when you have time. Today you need a path that does not start in wp-admin.

What still works when WordPress does not

If the host keeps panel snapshots, use them when they include both the files and the database and you can live with their restore time. That rollback is often the fastest undo on a managed plan. It is also their timeline, their retention, and usually their disk. Treat it as a useful extra layer, not as the only copy you would describe to a client.

The old manual path still works for a small site: fetch the offsite zip, put the files back over FTP or SFTP, import the SQL dump in phpMyAdmin, and chase wp-config.php until the site answers. Slow, easy to get wrong, and honest. If you have no SSH and no agent, that is still the job.

The path this guide is for is a restore that runs on the server but not inside WordPress. Reaver Backup keeps the dashboard outside the site — under /var/www/reaver/, any directory the web user can serve, or a different machine. The agent on the web host is what writes files back onto the docroot and imports the dump. You need a snapshot that already exists, and you need that agent online. You do not need wp-admin. If the agent is offline or cannot unlock the repo, fix that before you chase WordPress.

The Reaver path on the same server

On the Reaver Backup dashboard go to the Restore page, pick the site, then a snapshot, then restore onto this agent's path. The job writes back onto the WordPress root the agent already knows. Watch Active job on that page, and the full history on Jobs, until the restore is actually finished. Queued is not finished.

The operator steps, including the confirm step, live under Overwrite the site on this agent in Restore. This guide will not paste that checklist. Today's job is simple: dashboard outside WordPress, pick a snapshot the agent can unlock, put files and database back on this machine.

Restore is not a polish pass. Object caches, page caches, and opcode caches can keep serving the broken site after the files on disk are fine. Permissions on wp-content/uploads are a common leftover. A mu-plugin or a drop-in that was the original problem can come back with the snapshot if you picked the wrong point in time. Look at the site with a fresh request before you call it done.

If MySQL on that host was emptied or rebuilt, the docs cover importing the dump when the database is not ready. That is still same-server recovery. It is not a new box.

Same server vs new server

Treat these as two different recoveries.

If the server is up and only WordPress is dead, you are on this page. Keep the agent you already have. Restore from a snapshot that agent can still read — local on that host or offsite — it does not matter where the repo lives as long as it unlocks. If even a local repo on that box will not unlock, WordPress is not your main problem anymore; fix the agent, the password, or the disk first.

If the box is gone, that is the other recovery: pair a new agent on a new host, attach the destination that still holds the snapshots, restore files and database, and then you still do the vhost, the certificate, and DNS yourself. Reaver does not enable the site in Nginx or Apache. That walkthrough and the video are on Restore onto a new host.

Same-host overwrite and new-host recovery are easy to mash into one sentence. They are not one sentence. Mixing them is how people stare at an empty new server waiting for a dashboard button that was meant for the old path.

What you needed before the emergency

A restore on this morning is only as good as a snapshot you took on a normal day. The useful bar is not "a job ran." It is a backup you have actually restored, even onto a scratch path, so you know the files and the dump belong together.

For a white screen on a living box, a readable local repo is often enough. Offsite to S3, Backblaze B2, or SSH is what you want when the disk or the host is the problem — including the new-host path. Solo exists for one site that needs that destination. The first-backup walkthrough is here.

Leave the old plugin installed until you trust a Reaver snapshot. Two layers on the way in is not a mess. Uninstalling Updraft the afternoon of the first backup is how you strand yourself between systems. Reaver does not import that plugin zip anyway — the longer switcher notes are in Coming from UpdraftPlus, BlogVault, or BackupBuddy.

Who should stay on a plugin anyway

If you cannot SSH to the server, you cannot put an agent on it, then Reaver is the wrong tool for this morning. Shared hosting with only wp-admin is still plugin territory. Stay there, keep an offsite copy, and accept that a white screen means FTP and a dump.

If you have one small site and a few hours of hand rebuild would not sink you, the plugin plus a host snapshot may already be enough. The Reaver Backup layer pays off when the site is a store, a lead machine, or a client you would have to call — and when you already have SSH.

Short answers

Can UpdraftPlus restore if wp-admin will not load?\ Usually no. Restore is a WordPress screen. You can still use an offsite archive by hand if you have one.

Is a host snapshot enough?\ It is a good undo on that host when the panel actually has files and database together. It is not the same as a destination you own, and it does not help if the host account is the thing that failed.

Does Reaver restore without WordPress booting?\ Yes, on the same server, from the Reaver dashboard onto the site path the agent already has. WordPress does not have to load for that job to run.

Do I need a new server?\ Not for a white screen on a living box. You need a new server when the old one is gone. That path is restore onto a new host.

Will Reaver import my old plugin zip?\ No. Keep the zip until you have a Reaver snapshot you have restored. Then it is an extra archive, not the system of record.

Prove this before you need it

The free edition covers one site on local storage and does not need an account. Use it to take a snapshot and practice a restore onto the same agent while the site is still healthy. Add offsite when you care about disk or host loss — not because a white screen requires it. Editions and destinations are on Pricing.

The click path is First backup. The restore screens are Restore.