How to create a disaster recovery plan for your WordPress site

Nobody thinks about a recovery plan until the day they open their website and see a white screen or, worse, a "Hacked by…" page. That is when the questions you should have asked earlier appear: where is the last working copy? Who has the passwords? How long will it take to get back online? A disaster recovery plan is precisely the answers to those questions, prepared in advance, so you are not hunting for them under pressure.

We are not talking about something reserved for corporations with entire IT departments. If your website brings in customers, orders or simply represents your business, you need a plan like this. The good news is that it can fit on a single page.

What can actually go wrong

In almost two decades of looking after WordPress websites, we have seen the same four scenarios repeat, regardless of the size of the business. Let me list them without drama, because each one has a solution if you are prepared:

• A hacked site. Somebody injects code, redirects your visitors to other pages or steals your customer data. It often starts with an outdated plugin.
• A failed update. You hit "Update" on a plugin or theme and, instead of a new version, you get a fatal error. The site is stuck at exactly the moment you needed it most.
• A server outage. Your host has a failure, a disk gives out or the account is suspended. It is not your fault, but it affects you directly.
• Human error. You delete a page by mistake, overwrite content, push a change straight to the live site. It happens even to experienced people, on a busy day.

Notice what they have in common? None of them warns you in advance. That is exactly why preparation matters more than reaction.

How to prepare: the four parts of the plan

A good plan does not need dozens of tools. It needs four things set up properly.

1. An external, tested backup

This is where most people get it wrong. They have a backup, but it sits on the same server as the site. When the server goes down or is compromised, the safety copy disappears along with the original. A real backup lives somewhere else: in the cloud, on another server, somewhere you can recover it from even if your current hosting no longer exists.

More importantly still: a backup you have never restored is just an assumption. We have met clients convinced they were covered, until the file turned out to be corrupted or incomplete on exactly the day they needed it. That is why we insist that every backup is tested, not merely generated. If you want that worry taken off your plate, our WordPress backup service handles external, automated and regularly verified copies.

2. Documented credentials

In a crisis you lose precious time hunting for passwords in old emails. Write down in a safe place (a password manager, not a text file on your desktop) everything you would need to rebuild the site from scratch:

• hosting and control panel logins (cPanel, Plesk or equivalent);
• the WordPress administrator username and password;
• FTP/SFTP and database access;
• where the domain is registered and who controls it;
• your suppliers' contacts, with support numbers.

If you were unavailable tomorrow, could somebody else on the team start the recovery with what you have written down? If the answer is "no", the plan has a hole in it.

3. RTO and RPO, in plain language

Two technical terms that sound complicated but mean simple things. They are worth understanding, because they dictate how often you back up and which hosting you choose.

RTO (Recovery Time Objective) answers the question "how quickly do I have to be back online?". For an online store in peak season, one hour of downtime can mean serious losses, so the RTO is short. For a personal blog, a day is not a tragedy.

RPO (Recovery Point Objective) answers "how much data can I afford to lose?". If you back up once a day and disaster strikes in the evening, you can lose the whole day's orders. If that is unacceptable, you need more frequent backups. An active store wants an RPO of a few hours; a brochure site that rarely changes gets by with a daily one.

In short: RTO is how long you wait to come back, RPO is how much of your work you lose. You set them based on what each hour offline actually costs you.

4. Restore steps, written in advance

In the middle of a crisis, memory fails you. A useful plan has the steps written down clearly, like a recipe you follow calmly: where you log in, which backup you choose, in what order you restore files and the database, how you verify everything works afterwards. It does not have to be complicated, it just has to exist in black and white.

A concrete scenario

Let us see the plan in action. You run an online store. On Tuesday morning, a customer calls, upset: they open the site and get redirected to a dubious pharmaceutical page. You are the victim of a hack that started with an outdated plugin.

Without a plan, you would panic: hunting for passwords, calling the host in desperation, trying to manually delete code you do not understand and, meanwhile, losing sales and customer trust.

With a proper plan, things go differently. You open the document with the credentials and the restore steps. You put the site into maintenance mode temporarily, so visitors are no longer exposed. You pick the last clean external backup, the one from before the infection. You restore it following the noted steps, then change all the passwords and update the guilty plugin. In roughly an hour you are back online, with minimal losses. The difference between the two versions is not luck, it is preparation.

How to test your plan

A plan you have never rehearsed is a nice theory. Testing does not mean waiting for the disaster; it means simulating it in a safe environment:

• Restore into a test environment. Take the latest backup and rebuild the site on a subdomain or a separate server. If you succeed there, you will succeed when it counts.
• Time it. Note how long it actually took. If it takes far longer than your target RTO, something needs adjusting: either the hosting or the procedure.
• Check integrity. It is not enough that the site starts. Are the orders there? Do the forms work? Do the images load?
• Repeat regularly. A website changes over time. Run the test at least a few times a year, so the plan stays valid.

If this feels like too much to carry alone, you are not obliged to do it all yourself. A free audit of your website shows you exactly where you stand on backups, security and weak points, before they become an expensive problem.

Peace of mind comes from preparation

A recovery plan is not about fear, it is about control. When you know there is a clean copy of the site safely stored somewhere, that the credentials are written down and that you know exactly what to do, an incident stops being a catastrophe and becomes just a less pleasant hour of your day.

Start with the most important step: an external, tested backup you can rely on. From there, the rest of the plan builds itself naturally. And if you want somebody alongside you who has been through hundreds of situations like this since 2005, we are here. Write to us and let us make sure that, whatever happens, your website has a way back.