A backup is a timestamp, not a trust label
- estimate the earliest reliable compromise time
- compare multiple backup generations
- review files, database, and accounts together
- test restoration in isolation
- update and rotate secrets after recovery
An older backup may be cleaner but lose more business data. A newer copy preserves more data but may also preserve persistence. Document this tradeoff.
Restoring without closing the entry point may make the recovered site immediately vulnerable again.
Prefer rebuilding trusted application code and importing only reviewed content. Follow with integrity, functional, and security checks.
How do you select a recovery point?
Compare the earliest supportable anomaly with the creation time, storage path, and content of several backup generations. Do not inspect files alone: unknown users, malicious options, injected posts, and scheduled actions may live in the database.
A backup predating the visible symptom may already contain dormant persistence. A later backup may still hold valuable non-executable business data. Assess application code and content separately.
Why restore in isolation?
Restore candidates in a contained environment without public exposure or production secrets. Review versions, users, files, database content, and known indicators. Prevent cron, email, webhooks, and payment integrations from performing real actions during testing.
This exercise also confirms that archives are complete, decryptable, and technically recoverable before a production plan depends on them.
Restore or rebuild?
Rebuilding WordPress core, plugins, and themes from verified sources is usually easier to validate. Import only necessary, reviewed content from backups. Custom code requires a known repository version.
Close the suspected entry path, update components, rotate secrets, and test business processes. The persistence guide covers additional layers, while the hardening checklist defines acceptance controls.