A successful backup job does not prove recoverability. WordPress recovery depends on a matched database, application files, uploads, server configuration, credentials, DNS knowledge, and someone who can execute the sequence under pressure. Testing reveals missing pieces before an incident does.
Decision snapshot
| Decision | Practical approach | Watch for |
|---|---|---|
| Set recovery objectives | Choose an acceptable recovery time and maximum data loss based on business impact. | One nightly copy may be inadequate for a busy store. |
| Separate copies | Keep protected backups outside the live hosting account and use retention tiers. | Malware or account loss can affect colocated copies. |
| Test the full journey | Restore into an isolated environment and verify critical functions and data freshness. | An archive opening successfully is not a business recovery test. |
Inventory everything recovery requires
Document database, WordPress files, uploads, custom server rules, certificates, DNS, cron, external service settings, encryption keys, and access ownership.
Design backup frequency and retention
Map data change rates to recovery objectives. Use automated, monitored copies with daily and longer retention as appropriate, and protect deletion or immutability controls.
Verify each backup job
Alert on missed or unusually small archives, confirm encryption and offsite transfer, check database export completion, and record the application version associated with the copy.
Run an isolated restore
Provision a clean destination, restore database and files, adjust environment settings, keep it private, and time each step. Do not overwrite production for a drill.
Perform recovery acceptance tests
Check login, pages, media, forms, search, orders, scheduled tasks, integrations, permissions, and security controls. Record gaps and update the runbook.
Action checklist
- Backup scope includes database, uploads, code, and critical configuration
- At least one protected copy is outside the production account
- Job failures and abnormal archive sizes alert an owner
- Credentials needed during recovery are available securely
- Restore has been tested in an isolated destination
- Recovery time, restored data timestamp, and defects are recorded
Working worksheet
Record these fields in the same working document so the decision can be reviewed and handed off:
- System or data set
- Maximum tolerable data loss and downtime
- Backup frequency, location, encryption, and retention
- Restore dependency and access owner
- Last test date, actual duration, result, and next action
Common failure patterns
- Keeping only one rolling backup that a delayed incident can contaminate
- Excluding uploads or server configuration because they are not in the database
- Scheduling tests without assigning remediation for failures
Connect this work
Staging controls prevent a test from affecting visitors. Read use an isolated environment for restore drills.
WordPress is only one part of operational continuity. Read fit website recovery into the wider business plan.
Restoration should follow containment and evidence decisions. Read define when recovery is activated.