Your website is down. When did you last check your backup?

At 8:50 on Tuesday morning, your manager messages you: “The website is showing a blank page.” Half an hour later, you discover that a plugin updated overnight, and now neither the catalogue nor the admin panel will open. You reply calmly: “It’s fine, we have backups.” That’s when things get interesting.

Who makes them? The hosting provider. Good, and what date is the latest one from? We’ll have to check. Who knows how to restore it? Oleg, the contractor, probably. Oleg is on holiday. Once the restoration is finished, another small detail emerges: the backup was made at three in the morning, so it doesn’t contain the previous evening’s orders.

It’s a common situation: the owner sincerely believes backups exist, and technically they’re right. But “we have backups” answers only one of four questions. The other three are: what exactly will we lose, how long will the website be down, and who will press the button?

Throughout this article, I’ll use one hypothetical example: an online shop selling spare parts for agricultural machinery. It has a catalogue of several thousand products, orders from farms, two managers, and a WordPress website with WooCommerce. The story is invented, but every problem in it is an ordinary one.

When your website is down, the mere existence of an archive won’t tell you much. You need to know two numbers.

How much data you’re willing to lose. If a backup runs once a day, you could lose almost a full day in the worst case: new orders, price changes, new products and registered customers. This is your data loss limit. For a simple business website where the text changes once a quarter, losing a week’s changes barely hurts. For a spare parts shop during the farming season, even half a day’s orders mean calls to angry farmers and manually reconstructing orders from emails.

How long your website can be down. This is your recovery time. It includes the time spent finding access credentials, performing the restore and checking the result. Your hosting provider may promise a “one click” restore, but someone still has to click, and that person needs access.

Write these two numbers down before an emergency, rather than making them up during one. Say our hypothetical shop decides it can lose no more than one hour of orders and be down for no more than four hours. Those two lines inform almost everything that follows: how often to make backups, where to keep them and who to wake up if something breaks.

Take an ordinary day and look at what changes on your website between two backups.

For example, the spare parts shop receives 30 orders a day, and a manager updates prices from a supplier’s spreadsheet in the evening. The backup runs at three in the morning. The failure happens at 16:00. That leaves thirteen hours between them: yesterday evening’s orders, this morning’s orders, updated prices and two new wholesale customers with individual discounts.

Some of this can be recovered from elsewhere. Order notifications are in your email, payments are in your payment provider’s dashboard, and shipping documents are with the delivery company. But a person will still have to reconstruct those orders by hand from emails, and they probably won’t thank you for it.

WordPress documentation offers a starting point: back up small websites with few changes once a week, active websites daily, and always before an update (WordPress: Backups). For a shop receiving orders throughout the day, “daily” is often not enough, so the database should be backed up more frequently than the files. Files such as themes, plugins and product photos change less often. Orders live in the database.

What to do: ask whoever manages your website how often the database is backed up and at what time. Compare the answer with the number of orders or enquiries you’re prepared to reconstruct by hand.

A typical WordPress website needs two parts backed up: files and the database. The official documentation explains that a file backup does not include the database, because the database is stored in a separate system (WordPress: Backups, database backup guide).

Even a complete “files plus database” archive often leaves out things your business needs to get running again. Go through this list:

• Email. Mailboxes hosted by your provider usually exist separately from the website. The UK’s National Cyber Security Centre, NCSC, specifically lists email, invoices, contacts and customer data among the things a business should back up alongside its website (NCSC: Backing up your data).
• Domain DNS records. If these are changed or deleted, your website and email will no longer be found, even if both are intact. A screenshot or export of the records, saved separately, is enough.
• Server settings. Redirect rules, passwords for administrative areas and access restrictions often live in the server configuration, not in WordPress.
• Integration keys. Payment providers, delivery services, inventory synchronisation or accounting software. Sometimes these need to be connected again after a restore, so it’s best to know where to find the credentials in advance.
• Files outside the website. Product photos may be stored in a separate cloud service, while enquiry forms may run through a third party.
• Scheduled tasks. Overnight price updates, marketplace exports and customer reminders.

This is where our hypothetical shop encountered its first surprise. Product photos had been uploaded to separate storage for years and were not included in the website archive. The restored catalogue looked like a shop window after stocktaking: the names and prices were there, but the pictures had been replaced by grey squares.

Keeping a backup with the same hosting provider as your website is like taping a spare key to the same door. Very convenient, as long as the door is still there.

The problem is that common emergencies can affect that very place. The hosting provider suspends the account over an unpaid bill. Someone gains access to the account and deletes everything, backups included. The server is damaged. In each case, your website and its rescue plan disappear at the same time.

WordPress recommends keeping several recent backups in different places: with your hosting provider, in cloud storage and locally (WordPress: Backups). NCSC adds two important details: an external drive should not remain permanently connected to your computer, because some viruses can reach it too, and cloud storage containing backups should be protected with two step verification (NCSC).

I recommend one more simple precaution: use different credentials for the external backup and the website. If one password opens both the website and the backup storage, anyone who steals it gets both. Separate accounts and different people with access are a little less convenient day to day, and a lot more convenient on the day of an emergency.

I explained how to assess a hosting provider from this angle in “How to Choose Web Hosting and Not Discover the Limits on the Day of Your Sale”. The point here is simple: hosting backups are useful, but they shouldn’t be your only copies.

Few people think about this question, but it determines whether a backup can save you after a hack.

A hacked website rarely goes down immediately. More often, it runs normally for weeks while someone else’s code sits deep inside it, sending spam, replacing links or waiting for its moment. The problem comes to light when customers complain about strange redirects or the hosting provider blocks the account.

Now imagine your hosting provider keeps only the last seven daily backups. The hack happened three weeks ago. All seven backups already contain the same malicious code. Restoring any one of them gives you a hacked website again, just a slightly older version.

That’s why a useful retention plan goes back further: daily backups for the last week or two, weekly backups for a month or two, and monthly backups for a longer period. The exact numbers depend on the website and your storage budget, but the idea is simple: have at least one recovery point guaranteed to be older than the problem.

In its guidance on hacked websites, WordPress recommends asking your hosting provider exactly how it stores backups and planning for them in advance as part of keeping the business running (WordPress: FAQ My site was hacked). I’ll add this: ask before anything happens. It’s better to hear “we keep three days” while you’re still calm.

A shop’s backup contains everything: customer names, phone numbers, delivery addresses, order histories and sometimes password hashes. That’s your entire customer database in one file.

We’ve seen SQL database copies left directly in a website folder after a move to another server, where anyone with the direct link could download them. The website worked, and nobody noticed. The old server had its own rules blocking access to those files, but the new one didn’t read those rules.

That’s why backups need a few security rules:

1. Don’t keep archives in a public website folder where anyone who guesses the filename can download them. Names like backup_new_2_ok.zip are easier to guess than you might think.
2. Encrypt backups stored outside your hosting provider, and store the encryption password so that two people can find it, not just one.
3. Limit who can download a backup. A contractor may need it for their work; an SMM intern probably doesn’t.
4. Delete old backups according to a schedule, rather than waiting until the disk runs out of space.

If your website has recently moved, check separately after the move that administrative files are protected.

The best way to find out whether your backup works is to restore the website from it on a quiet day. Do it in a separate test copy, not on the live website. Think of a fire drill: nobody sets anything on fire, but everyone really does leave the building, and someone stands there with a stopwatch.

Here’s how our hypothetical shop ran its drill.

Preparation. They chose a day with few orders. The contractor created a separate test subdomain, protected it with a password and blocked indexing so the test copy wouldn’t appear in Google or draw visitors away from the live website.

Start the stopwatch. They started the clock when the owner said, “Let’s imagine the website is down,” not when the restoration began. In a real emergency, the first few minutes are also spent looking for access credentials rather than doing the work.

Restore. They took the latest backup of the files and database from wherever it was stored outside the hosting provider and restored it on the test subdomain.

Check. They went through the website as a customer and as a manager:

• homepage, catalogue, search and several product pages with photos;
• prices match the date of the backup;
• login to the admin panel works;
• checkout reaches the payment step in test mode, without real charges;
• the contact form sends an email to a test address.

Before testing, turn off mailing campaigns and customer emails on the test copy. Otherwise, the restored database may dutifully remind farmers about baskets they abandoned back in spring.

Record. They wrote down four things: the date of the backup, the total time from “down” to “working”, what wasn’t restored and who did what.

The hypothetical shop’s result was instructive. The backup itself worked. But it took more than three hours from the start to a working website: they spent an hour finding out who had access to the external storage, then discovered that product photos weren’t included in the archive and that they would have to request the payment provider’s key again. That still fits within the four hour limit, but leaves no room to spare. After the drill, they added photos to the backup, recorded access credentials in the company password manager and put integration keys in a separate secure document.

How many times a year you do this is up to you, but once a quarter and after every major website change seems like a reasonable minimum to me. A major change could be a move, a new payment module, or a switch to another theme or platform.

When your website is down, the strongest temptation is to press “restore” as quickly as possible. Sometimes that’s the right call. But for a shop, there’s a catch.

If the failure happened at 16:00 and the backup is from 3:00 in the morning, restoring the database over the current one will overwrite everything that appeared between those times, even if the data is still physically on the server. So do three things before restoring:

1. Save the current state, even if it’s broken. A copy of the database made during the emergency may contain those thirteen hours of orders. The website might not open, while the database is still perfectly intact.
2. Export or write down new orders. Use the admin panel if it works, or order notifications in your email and the payment provider’s dashboard.
3. Restore to a test copy first, if time allows, and only then move it to the live website.

If an update caused the failure, rolling back the plugin or theme often solves the problem without restoring the entire database. You need someone who understands the difference, which is why it matters to know who that person is in advance.

One more habit often saves the day: make a fresh backup immediately before any update. WordPress recommends exactly that (WordPress: Backups). An automatic overnight update without a fresh backup beforehand looks like a bold experiment, with you as the test subject.

A recovery plan doesn’t have to be a thirty page document. One page is enough, as long as you can find it when the website is down. That means keeping it somewhere other than on the website itself or only in email hosted by the same provider.

That page should say:

• who decides to restore and which backup to use;
• who performs the technical restore, and who stands in if that person is unavailable;
• where the backups are and how to access them;
• hosting support contacts and the contract or account number;
• who informs the managers and what they tell customers while the website is down;
• the agreed data loss limit and recovery time.

If this list makes you realise that your contractor still holds half the access credentials, start with the access check in our article “Your contractor disappeared. What’s left of your website?”. Without access, a recovery plan is little more than a nice wish.

You can copy this message and send it to whoever currently manages your website. The answers will give you roughly the same picture as a drill, just without the stopwatch.

If question seven is met with silence, that’s an answer too.

You don’t need to rebuild everything at once. Here’s a short order of operations:

1. Write down two numbers: how many hours of orders or enquiries you’re prepared to lose, and how many hours your website can be down.
2. Send the message above and get the answers in writing.
3. Make sure at least one backup is stored outside your hosting provider, with separate access.
4. Set a date for your first drill and start the stopwatch.
5. Put together a one page recovery plan and keep it somewhere people can find it without a working website.

If you’d like a fresh pair of eyes, we can check your website, backups and access. And if your website needs to be rebuilt with backup and recovery planned from the start, take a look at our websites and e-commerce page.