A backup from before the visible redirect or spam is not automatically clean. Attackers may remain quiet, and the vulnerable plugin, stolen account or malicious scheduled task can exist days before the first public symptom.
Treat the backup as a recovery candidate and test it in isolation.
Build the incident timeline
Record first observed symptom, earliest suspicious login/request/file/database change, last known good business event and the backup creation time. Use one timezone.
Include plugin updates, migrations, new administrators, password resets and provider alerts. Do not choose a backup solely because its filename says "pre-hack."
State where log retention leaves gaps.
Verify backup origin and integrity
Confirm which system created the filesystem/database backup, which site/database it covers, and whether it completed successfully. Record size, timestamp and checksum where available.
Store it outside public web roots and restrict access; backups can contain credentials and customer data.
Do not rely on a copy created by an unknown job after hosting access was compromised.
Check vulnerable components
Inventory WordPress, PHP, plugin and theme versions inside the backup. Compare them with the suspected vulnerability prerequisites and disclosure timeline.
An older backup often contains older, more vulnerable software. It can preserve the entry point even if no payload is visible.
Plan to rebuild maintained code from trusted current packages, not run the archived packages unchanged.
Inspect users and credentials
Review administrators, application-password metadata, user emails/roles and relevant hosting/deployment accounts from the backup date. Check for unknown users or changed recovery addresses.
Do not copy password hashes into reports. Assume database and embedded API credentials may need rotation after restoration.
Compare with the verified owner inventory.
Search for persistence indicators
Inspect must-use plugins, uploads/cache executable files, wp-config.php, root/server rules, WordPress cron, database options and injected page-builder content.
Use known incident indicators but do not limit the review to one filename; a backup may contain an earlier loader. Avoid executing suspicious code during inspection.
Check staging and sibling-site links.
Restore into isolation
Bring the candidate into a non-public environment with no production SMTP, payment or webhook credentials. Block external callbacks and indexing.
Install trusted code separately and import assessed database/uploads. If the archive must be booted for analysis, use strict isolation and do not grant it production access.
Never point live DNS at the candidate as the first test.
Review backup automation and retention
Inspect the job, storage account and restoration history. A compromised hosting account may alter backup schedules, include attacker files or delete older clean copies.
Verify off-site repository users/tokens and rotate exposed access. Do not trust a backup solely because the provider dashboard marks it successful.
Keep several dated candidates until analysis selects one.
Reconcile missing business data
Estimate orders, users, form entries, stock/content changes and payments created after the backup. Identify authoritative external sources such as the payment provider.
Do not overwrite live WooCommerce data with an old database without an explicit reconciliation plan. Content may be imported selectively into a clean build.
Protect customer data throughout comparison.
Define acceptance criteria
A usable backup has a trustworthy origin, predates earliest credible compromise, supports clean-code rebuild, contains no known persistence and can be reconciled with current business data.
If these cannot be demonstrated, rebuild from trusted software and import validated content rather than choosing an even older snapshot blindly.
Document confidence and remaining uncertainty.
Verify after recovery
Test users, cron, redirects, forms, checkout, payment sandbox, mail and uploads. Rotate exposed secrets and close the entry vector before reopening.
Monitor original indicators and privileged changes after release. Retain the candidate and evidence under the incident policy.
Request urgent recovery assessment when backups and order history conflict. Share timestamps, inventories and redacted indicators—never backup archives, database dumps or credentials publicly.