Skip to content
BackupTool.com
Recovery practice / FIELD GUIDE

Your WordPress admin will not open. Can you still reach your backup?

Prepare a WordPress recovery plan before an outage. Know who can access hosting, find backup files and authorize a restore without using wp-admin.

THE SHORT ANSWER

Keep a recovery route outside the website itself.

A backup is harder to use if the only way to reach it is through a broken WordPress dashboard. Before an incident, identify your hosting access, backup location, provider instructions and the person allowed to authorize recovery. Do not start overwriting files just because the login page fails.

A CLEARER VIEWBuild a recovery access map.
  1. People

    Name the owner, technical contact and recovery decision-maker.

  2. Access

    Know how authorized staff reach hosting and storage separately.

  3. Process

    Keep the provider’s recovery instructions and a record of the chosen backup.

Use this as a planning aid. A plan is not a completed backup or a recovery test.

A failed login page does not tell you the cause

A blank screen, an error message and a rejected password can have different causes. None of them, by itself, proves that the site needs a full restore. Start by recording the exact symptom, when it appeared and any change made shortly beforehand.

Ask your host or maintainer whether the issue affects the website, hosting account or sign-in process. Keep the current files and database available where possible. Repeatedly deleting plugins or importing older data can make it harder to understand the original problem.

List the access you would need

Check who controls the hosting account, domain, backup storage and recovery email. These may belong to different people. For an agency, the person who updates the site may not have permission to restore the hosting account or change the domain.

Store credentials in a suitable password manager and arrange an authorized recovery method for account access. Your written checklist should say where access is managed, not copy secret keys or passwords into a client report. Review permissions when staff or service providers change.

Find the archive before an emergency

Locate a recent backup and read the provider’s instructions for using it. Note whether it is a full account snapshot, a plugin-specific set or only a database export. An archive name is not enough to establish that it contains everything the restore method expects.

If the plugin offers an independent recovery package, learn its requirements in advance. If your host performs restores, record how to contact support and what information they need. Do not assume a method from a different plugin will accept the files you have.

Decide what may be replaced

Before authorizing a restore, compare the backup’s time with the last known working state. Identify new orders, bookings, uploads or account changes that happened afterwards. Replacing an older database can replace those newer records too.

Agree whether the proposed action affects one website or a wider hosting account. Ask for help with a test copy when the impact is unclear. If a security incident is suspected, recovery also needs investigation and appropriate cleanup; putting old files back is not automatically a complete security response.

Illustrative example

A plugin update broke the admin page at noon, but orders arrived until 2 pm. Restoring the entire database from 11 am without a reconciliation plan could remove those later orders.

Rehearse the handover, not a surprise live restore

A simple preparation exercise is to ask an authorized colleague to follow the written access map. Can they identify the host, locate the provider instructions and name the person who may approve recovery? They do not need to restore the live site to reveal missing contact details.

A real recovery test belongs in an appropriate separate environment with a clear scope. Record the backup used, the checks performed and the limitations. Update the access map afterwards. The result should make the next incident less confusing, without pretending that every possible outage has been tested.

PUT IT INTO PRACTICE

Your next steps

Use these checks as you work. Ticks stay on this page and are not saved as monitoring or recovery evidence.

Where BackupTool fits

BackupTool’s site histories and customer-recorded tests can help explain earlier observations and recovery notes. They do not replace hosting credentials or the backup archive. BackupTool has no standalone restoration engine and cannot recover a broken WordPress installation for you.

See how backup monitoring works

Sources and further reading

Prepared on 21 October 2026 using the linked documentation. Examples are illustrative. Check your provider’s current instructions before changing backup or recovery settings.

KEEP READING

The next useful question.