How to Restore a WordPress Backup Safely After a Hack

Security guidance · Checked 31 October 2026

In this guide

1. Establish what the backup includes
2. Compare backup dates with the incident timeline
3. Protect recent orders, bookings and content
4. Restore privately before making it public
5. Repair the weakness before relaunch
6. Use a practical acceptance checklist
7. Plan the cutover and keep a rollback decision
8. When a backup is missing or unusable
9. Frequently asked questions

A backup can make recovery much easier, but the newest copy is not automatically the right one to restore. It may already contain the compromise, and replacing the database can remove legitimate activity that happened after the backup was taken.

The right starting question is not simply “Do we have a backup?” It is “What does this copy contain, what would a restore replace, and how will we confirm the recovered site is suitable to go live?”

Establish what the backup includes

WordPress normally needs both website files and a database to restore the full installation. The official backup handbook explains that these are separate parts of the site.

Check the actual scope: uploaded media, plugins, themes, configuration, database tables and any external storage or integrations. A content export, a screenshot archive and a full hosting snapshot solve different problems.

Also confirm that the backup can be downloaded and that the responsible person has a supported restoration method. A dashboard showing “backup enabled” is not the same as a tested recovery copy.

Compare backup dates with the incident timeline

Record when the first symptom was seen, then look for earlier evidence where logs or change records exist. The first visible redirect may be later than the original unauthorised access.

Review available restore points with that uncertainty in mind. Do not label a backup “clean” solely because it predates the customer’s complaint. Test and inspect the candidate before putting it back into public use.

Keep the current affected state separately where possible. It may help explain what changed and preserve legitimate content that would otherwise be overwritten.

Protect recent orders, bookings and content

A whole-database restore can undo valid business activity. On a store or membership site, make a specific plan for transactions and account changes since the restore point.

Decide what needs reconciliation and who is responsible for it. Check whether external payment, booking or accounting systems hold records that must remain consistent with the restored website.

Do not manually re-create payment records or mark transactions successful without verification. If recovery touches commerce data, involve the person responsible for the existing order and payment integration.

Restore privately before making it public

Where the platform supports it, restore the candidate into an isolated environment. Restrict access and ensure it cannot accidentally send customer emails, run live payment actions or overwrite production data.

Check environment-specific settings carefully. A copy of a production site may retain webhook destinations, scheduled jobs and connected API accounts. Staging should not become a second live business system by accident.

If hosting limitations prevent an isolated restore, document that limitation and agree a carefully controlled alternative with the maintainer. Do not hide the lack of a test environment from the decision-maker.

Repair the weakness before relaunch

A restore may replace visible damage while bringing back the same vulnerable component or unauthorised account. Apply the appropriate fixes, review access and remove confirmed malicious material before reopening the site.

If you do not know how the compromise occurred, keep that uncertainty explicit and agree additional checks. Do not claim that selecting an older date automatically removes every risk.

For recurring problems, the backdoor and reinfection guide explains why persistence and access paths need attention alongside file restoration.

Use a practical acceptance checklist

Before launch, verify the parts of the restored site that customers and staff actually use:

• Public pages and the URLs originally affected.
• WordPress login and appropriate user permissions.
• Contact, registration or booking forms.
• Media, downloads and important uploaded documents.
• Product, cart and checkout behaviour where included in scope.
• Email and external integrations using a controlled test method.
• Updated components and the access changes agreed for recovery.

Record any unresolved issue and obtain approval for the go-live decision. A restored homepage is only one item in that checklist.

Plan the cutover and keep a rollback decision

Agree a change window and how new writes will be handled while the restored site replaces production. Keep a clear record of which file set and database belong together.

After launch, repeat the essential public tests and monitor the reported symptoms. Preserve the incident and restoration notes so a later maintainer can understand what was recovered and what data had to be reconciled.

Do not promise zero data loss. The outcome depends on the available copies, incident damage, external systems and the care taken during reconciliation.

When a backup is missing or unusable

Ask the host about retained copies and the exact retention policy. Also check whether another authorised maintainer holds a suitable archive. Avoid overwriting the remaining evidence while searching.

If no suitable copy exists, recovery may involve reconstructing components and carefully preserving legitimate data. That is a different scope from a straightforward restore and should be quoted accordingly.

NithuDev can help review the available options through the WordPress website recovery service. In your enquiry, describe the symptom, backup dates if known and whether the site takes orders or bookings. Share access details privately later.

Frequently asked questions

Is an XML export a full website backup?

No. It is a content-export format, not a complete copy of the runtime, every plugin and all database configuration. Confirm the actual coverage of your backup method.

Can I restore first and update later?

Avoid publicly relaunching a copy that retains the known exposure. Plan the supported fixes and access review as part of the recovery.

Can every lost order or upload be recovered?

Not necessarily. Available records and backup coverage determine what can be reconstructed. Agree the data risks before restoring.

Published by NithuDev. Contact Nithu / Suthakaran Nithursan, website developer and security recovery specialist. About Nithu. Featured artwork is an AI-generated illustration for this guide, not a photograph of a client incident or security evidence.