Could you restore your website without losing today’s orders?

Imagine your online store saves a backup every night. During the morning, several orders come in, customers register and stock levels change. At midday, something goes wrong and you need to restore last night’s version.

So far, that sounds like a reasonable solution.

The question comes next: what would happen to everything that has happened since that backup was taken?

When a website is part of your business, it helps to know what you would recover, how old that information is and how you would preserve the latest activity. Understanding that difference can save a great deal of work when you need to get back up and running.

A situation worth preparing for

In October 2026, Rank Math confirmed that some copies of its PRO version, distributed during a period of several hours between the 15th and 16th, contained malicious code. The free version was outside the reported scope of the incident.

For websites that had activated an affected copy, the vendor recommended, among other measures, restoring files and the database from a backup taken before the incident. It explains this in its official notice.

This particular case is a reminder of something important: recovery may mean going further back than we would like. We may also need to restore a site after an editing mistake, an incompatible update or a server failure.

How well we have prepared will determine much of the work that follows.

What a backup actually contains

In WordPress, two parts need to be considered: the files and the database.

The files include images, themes and plugins. The database stores content, settings and, in a WooCommerce store, information such as customers and orders. The WordPress documentation explains why both parts need to be covered for a complete recovery.

That makes it worth checking exactly what our backup service includes. Also, how long it keeps previous versions and whether we can access them even when the website stops working.

A recent backup helps. But if the problem was already present when it was taken, it may contain that problem too. Having several recovery points lets us look for an earlier state that will actually be useful.

This morning’s orders need particular care

Let’s return to our store. The backup taken at three in the morning may be perfectly sound. However, the orders placed at ten did not exist when it was saved.

If we replace the entire database with that version, we may overwrite the newer information. WooCommerce explicitly addresses this issue in its backup and recovery guide.

Before restoring, the technical team needs to assess which data can be preserved, which records are reliable and how they can be brought back safely afterwards. Orders, shipping statuses, customers and stock levels may all have changed. A list of order numbers may fall short of what is needed to reconstruct that activity.

Some WooCommerce solutions can preserve recent orders during certain restores. That ability depends on the tool and the procedure used: Jetpack documents differences between its recovery methods.

It is worth understanding those limits and testing the system before we need it. More frequent backups reduce the gap in unprotected data, but keeping everything also requires a properly designed recovery process.

A payment and its order need to tell the same story

After restoring the website, what the store displays may differ from what the payment system records.

If an order appears as pending or purchase information is missing, its details need to be checked against the payment gateway: amount, date, reference and transaction status.

This has a very practical consequence. Before asking a customer to pay again, we need to check what happened to the first attempt. WooCommerce recommends that check to avoid duplicate charges when a payment is uncertain.

We also need to review which orders had already been shipped, which returns were in progress and which messages customers had received.

The person who made the purchase needs to know whether their order is confirmed and what will happen next. A well-organised recovery should give the team reliable information to answer those questions.

Two questions to help choose the right protection

Before subscribing to a tool or upgrading the hosting, it is worth clarifying two things.

How long can we go without selling through the website?

One store may have some room to deal with an incident. Another may be in the middle of a campaign and need a much faster response. That requirement affects support, access arrangements and the recovery procedure.

How much activity could we reconstruct if some data were missing?

A daily backup may suit a website that changes infrequently. For a store making sales throughout the day, the same interval may leave too many orders to review.

These are business decisions with technical consequences. They help match the investment to actual activity and clarify what level of recovery we are paying for.

It also makes sense to keep a backup outside the website’s server. Learn WordPress recommends that separation so access to the backup does not depend on the same place we are trying to recover.

What to do before reopening the store

The procedure should be agreed with whoever maintains the website. When an incident occurs, it helps to follow an order:

1. Understand what happened and limit new changes where necessary. If data will be restored, checkout may need to be paused temporarily so new transactions do not keep arriving during the process.
2. Preserve the available information. Safely save the current state and any records that may be needed before replacing them.
3. Choose a valid recovery point and address the cause. If there was a security issue, recovery requires checking that the system is clean and reviewing affected access credentials.
4. Reconcile recent activity and test the full journey. Review orders, payments and stock levels, and carry out a controlled purchase check, including its confirmations and notifications.

Afterwards, keep monitoring how the site behaves in case unresolved issues appear. Seeing the homepage load is only one part of that review.

Rehearsing a restore in a separate environment lets us check that the backups work, understand the steps and estimate timings. It also helps uncover missing access or responsibilities that nobody had clarified.

Different businesses store their activity in different places

In the MyBooking integration with WordPress, bookings are created and stored in the MyBooking system. WordPress displays the booking engine to the customer and, through the plugin, communicates with the API to check availability, make the booking and receive the response.

Therefore, restoring a WordPress backup does not delete or roll back bookings recorded in MyBooking. Those records remain in its management system, regardless of which version of the website we restore.

A website outage can interrupt new bookings through that channel, but existing bookings remain available in the MyBooking dashboard. That separation between the website and business management is part of what we explain in our article on customising MyBooking in WordPress.

Knowing where each piece of information lives helps us prepare an appropriate recovery for each project. In a WooCommerce store with orders stored in WordPress, that database needs to be protected. With MyBooking, website recovery and booking preservation belong to separate systems.

Conclusion

Having backups is a good starting point. Their full value becomes clear when we know what they contain and have checked how to restore them.

For anyone running a business, four questions are worth being able to answer: who is responsible, how long getting back up and running could take, how far back the recovered information would go and how we would protect what happened afterwards.

With those answers, we can prepare a proportionate procedure, reduce improvisation and look after customer activity while resolving the incident.

If you would like to review how well your website is prepared for recovery, Tornem can help you check your backups and define a procedure suited to your business.