A backup is not preparedness until you have tested WordPress recovery
A controlled recovery exercise reveals whether the backup, access permissions, documentation and monitoring actually work when the company website needs to be rebuilt.
Category: Secure WordPress Operations
It is easy to tick off backup when the WordPress website is automatically saved every night. The difficult question is whether the backup can actually be used. A successful job notification only says that files and data have been copied. It does not say that the copy is complete, undamaged or possible to restore within an acceptable time.
A recovery exercise turns the backup into genuine preparedness. The exercise should take place in an isolated environment, not on the live website. The goal is to document the entire process, from the decision to recover to a controlled, updated and monitored WordPress website.
Define what the exercise should prove
Start with a specific scenario. For example, you might assume that the website database has been corrupted after an error, or that the production environment must be replaced because an unauthorised person may have gained access. The scenario determines what needs to be recovered and which checks must be carried out.
Also set a clear goal for the exercise. This could be that the website must be recoverable to an isolated environment, that critical forms must work, and that the responsible person must be able to document the point in time from which the data was retrieved. Avoid an unclear goal that merely says you are going to «test the backup».
Clarify in advance how much data loss the business can accept. A website that primarily provides information has different needs from a solution that receives orders, applications or customer enquiries. If the latest backup is from the previous night, new submissions may be missing even if the recovery succeeds technically.
Map more than the WordPress files
A company website often consists of more than the WordPress core, theme and database. A useful recovery plan must describe all the dependencies required for normal operation.
- WordPress files, uploaded media and database
- Server configuration, scheduled tasks and necessary settings
- DNS, certificates and any caching
- Form submissions, email delivery and integrations
- Analytics, consent management and other external services
- Access permissions, two-factor authentication and points of contact
- Monitoring, alerts and logging
If only the WordPress content has been backed up, a great deal of manual work may remain. Missing server settings can result in incorrect upload limits, broken scheduled tasks or weaker security settings than before the incident.
Verify that the backup is suitable
Before recovery, you should be able to answer four questions: When was the copy made, what does it contain, where is it stored and who has access? The backup should be stored separately from the environment it protects. If both the website and the backup depend on the same account or server, a single error or compromised access could affect both.
Verify that the files can be read, that the database can be imported and that the copy covers the correct website. This is especially important for businesses with multiple WordPress installations with similar names. Encrypted backups must have a documented and accessible key. A backup that no one can unlock during an incident has little practical value.
Access to the backup should be restricted. The backup may contain personal data, form entries, user accounts and configuration that should not be available to everyone with editor access in WordPress.
Recover in an isolated environment
Do not put an uncontrolled copy straight back into production. Create an isolated test environment that is not indexed, does not send email to customers and does not process real orders. Restrict access with separate authentication, and use administrator passwords different from those on the production website.
Log every step as you work. Note who performs the task, which copies are used, the time of recovery and any manual changes. This makes it possible to improve the procedure afterwards and reduces dependence on a single technician remembering everything.
- Create a clean and isolated operating environment.
- Recover files, media and the database from the selected point in time.
- Add the necessary server settings and scheduled tasks.
- Disable outgoing email, payments and other actions with external effects.
- Check users, software versions and security settings.
- Test page templates, forms, search and key integrations.
- Document errors, time spent and missing information.
Do not restore the vulnerability along with the website
An older backup may contain the same vulnerable extension or the same unknown administrator account that caused the problem. Recovery must therefore be followed by a security review before the environment can be considered ready.
Compare the installed themes and extensions with the business's approved inventory. Remove components that are not in use, and update WordPress, extensions and themes in a controlled manner. If a component is no longer maintained, you must consider replacing it rather than reactivating it.
Also look for unexpected administrators, changed email addresses, new integration keys and other anomalies. If compromise is suspected, passwords, keys and sessions should be replaced. Changing the password for just one WordPress user is not sufficient if server accounts, database users or external services may be affected.
Test authentication and access control
A recovered solution must not only display the correct pages. It must also have the correct access model. Verify that administrators use personal accounts, that two-factor authentication works and that former employees or suppliers no longer have access.
Test how the business can gain access if the usual administrator is unavailable. A contingency account may be necessary, but it should be stored securely, monitored and used only when the situation requires it. Shared administrator accounts make it difficult to see who has done what and should be avoided.
Remember access credentials outside WordPress. Domain management, servers, backups, email services and security solutions may be critical to getting the website back online. The plan should specify roles and points of contact, but do not distribute passwords or secret keys in an ordinary procedure document.
Test the functions the business depends on
A homepage that loads is not proof that the website works. Create a brief acceptance test based on what the website is actually used for. For a typical business website, the test may include navigation, contact forms, search, file downloads, login and the most important page templates.
Forms must be tested all the way from submission to receipt. Check that the confirmation page is displayed, that data is stored correctly, and that notifications reach the agreed recipient. In the isolated environment, use controlled test addresses so that customers or employees do not receive misleading messages.
For solutions involving orders or membership data, you should also check how information created after the backup point should be handled. Some data may be retrievable from an external system, while other data must be entered manually.
Restore monitoring before launch
Monitoring is often forgotten when attention is focused on the recovery itself. Before the website is put into operation, you must check that alerts for downtime, errors, certificates, suspicious logins and failed backups are active.
Also check who receives the alerts. A technical alarm is worthless if it goes to a closed inbox or to a provider that is no longer responsible. The alerting procedure should specify who assesses the incident, who can make changes, and who informs people internally.
End with a specific improvement list
After the exercise, you should gather the findings in a brief review. Distinguish between errors that prevented recovery, issues that delayed the work, and improvements that can be planned for later.
- Was the database or media files missing from the backup?
- Were the necessary access credentials available to the right person?
- Was the documentation up to date and easy to understand?
- Did outdated extensions cause errors?
- Did authentication and two-factor authentication work after recovery?
- Were critical functions and integrations tested?
- Did alerts reach the responsible recipient?
Assign each action an owner and a deadline. Then update the recovery plan while the experience is still fresh. If the exercise revealed that the backup is incomplete or that no one has access to it, this should be treated as an operational risk, not as a note for next year.
Make the exercise part of reliable operations
How often recovery should be tested depends on how often the website changes, how important it is to the business, and how much data can be lost. A new exercise is particularly relevant after changing the operating environment, making major technical changes, adding new integrations or changing the backup solution.
The most important deliverable is not a screenshot showing that the website started. It is a documented process demonstrating that the business can retrieve the correct copy, restore it in a clean environment, close old access, remediate vulnerabilities, validate critical functions and activate monitoring. Only then is the backup part of actual preparedness.
