A full backup combines trusted content with potentially vulnerable code, stolen accounts and persistence. Restoring the archive wholesale recreates the exact environment that was compromised.
Build a clean application and import validated data in controlled stages.
Preserve the current incident state
Snapshot filesystem, database, logs, users, cron and mail activity before restoration. Record containment actions and the original document root.
Keep infected evidence non-executable and outside public storage. Do not overwrite it with the backup or use the only copy as a working directory.
Protect customer/order data and limit access.
Choose a candidate data point
Compare backup time with earliest credible compromise and recent business activity. Inventory software versions, administrators and known indicators within the archive.
An old backup can be useful for content comparison without being safe to boot. Record missing orders, users, forms and uploads that require reconciliation.
Do not equate "before symptoms" with clean.
Create a clean document root
Install WordPress core, maintained plugins and themes from verified sources. Apply supported PHP, least privilege and production configuration without copying unknown code.
Review custom plugins/themes line by line from a trusted repository or known-good version. Remove abandoned components and replace their functionality.
Keep the infected root isolated and read-only.
Recreate configuration and secrets
Build a new wp-config.php structure using current database access and fresh authentication keys. Rotate SMTP/API, payment, backup, deployment and webhook credentials exposed to the old environment.
Do not copy secrets from the compromised archive. Verify DNS/CDN/hosting accounts and enable MFA.
Document secret owners without storing values.
Validate database content
Import the database into isolation and inspect users/usermeta, options, cron, snippets, redirects, widgets, posts/templates and custom tables.
Remove only confirmed malicious records through precise changes. Avoid global replacement across serialized data. Where integrity is uncertain, import content/orders through supported application tools into a fresh schema.
Retain row backups and identifiers.
Validate uploads
Scan and inventory media, blocking executable PHP and unexpected server rules. Confirm each file type is needed and do not copy cache, backup or temporary directories as media.
Preserve customer uploads under access/retention controls. Rebuild thumbnails and generated assets from trusted sources.
Do not open unknown files on an ordinary workstation.
Review external configuration
Audit DNS/CDN redirects/workers, tag-manager containers, Search Console owners, SMTP provider, payment administrators and backup/deployment accounts. Malicious behaviour can survive outside WordPress.
Revoke unknown users/tokens and compare deployed versions with approved history. Keep public DNS unchanged until the clean environment passes tests.
Do not restore old API tokens simply because integrations need them; issue new least-privilege credentials.
Reconcile current business data
Compare WooCommerce orders/payments, stock, users and form entries after the selected backup. Use payment provider and authorised records as independent references.
Import recent validated data without overwriting clean security configuration or duplicating transactions. Assign one authoritative order state.
Document exceptions requiring manual customer contact.
Test in isolation
Verify login, roles, forms, checkout sandbox, webhooks, cron, mail, redirects, language/mobile and backups. Inspect rendered code and network destinations.
Run through recurrence triggers such as cron cycles, cache warm-up and administrator login. Confirm no original indicators or unknown accounts return.
Keep analytics/payment production actions disabled until approved.
Prepare a reversible cutover
Record current/new document roots, database endpoints, DNS TTL and cache layers. Define rollback that returns to safe maintenance—not the infected application.
Prevent both old and new sites from accepting writable checkout/forms simultaneously. Reconcile submissions during the final transition window.
Reopen with monitoring
Switch DNS/document root only after acceptance criteria and rollback are ready. Monitor file/database changes, privileged users, outbound mail and original indicators.
Retain the old root and evidence under policy, then remove them securely. Review the initial entry point and patch/process failure.
Request emergency rebuild help when database/uploads and recent orders need selective recovery. Share inventories and managed access—never public archives, secrets or customer databases.