Monday morning. You open your website and it does not load. Or it loads, but the weekend’s orders are not there. You call the person who looks after it, and you hear the sentence you wanted to hear: “Don’t worry, we have a backup.”
Relief. You hang up and go for a coffee.
By midday nothing has been fixed. In the afternoon you learn that the backup is from the start of the month. In the evening, that the database is not restoring the way it should and that “we’re looking into it”. And somewhere around then you realise that “we have a backup” did not mean what you thought. It meant that a file exists somewhere. Nothing more.
The file is not the answer
You do not want a backup in order to have one. You want it in order to get back to work. Whether it will get you running again cannot be seen by looking at the file. It only shows when someone tries to restore it.
That is why “do you have a backup?” is the wrong question. You will almost always hear “yes”, and it will be true. The right questions are different, and there are six of them. You do not need to know anything technical to ask them. You only need to insist on a specific answer, and where possible, a number.
1. How much work could be lost?
If the backup is taken once a day, at midnight, and the problem happens at six in the evening, whatever happened in those eighteen hours is lost. Orders, bookings, messages from the contact form, changes you made to your products.
For a site that changes once a month, that may not matter at all. For an e-shop with twenty orders a day, it matters a great deal. There is no right or wrong answer in general. There is a right or wrong answer for your business, and you need to know it before something goes wrong, not after.
2. How long until the site works again?
“Quickly” is not an answer. Nor is “straight away”. Ask for a number: two hours? One working day? And ask what happens if the problem hits on a Friday evening. A failure does not check what time your provider’s office closes.
The clock starts when you report the problem, not when someone finds time to look at it.
3. What exactly does the backup contain?
A website is not one thing. It is its files (pages, images, design); the database holding your orders, your customers and everything else stored there; and often the settings that make it run. If your email is hosted with the same provider, ask whether the backup includes it too, because it cannot be taken for granted.
There may be a backup of the files and not of the database. The site then comes back, at best, looking right and empty. Like a shop rebuilt with empty shelves.
4. Where is it kept?
If the backup lives on the same server as the site, whatever hits one can hit the other. A disk failure, a wrong setting, a piece of malicious software that encrypts everything it finds. A backup sitting next to the original is like keeping the spare house key hanging on the front door.
The rule recommended by the US cybersecurity agency (CISA) is simple: three copies, on two different media, with one kept somewhere other than where the site lives. I covered it, along with the other basics of security, in “A secure site in 2026: why the padlock in the address bar is not enough”.
5. How old is the oldest backup you keep?
This is the question that is most easily forgotten.
We do not always notice straight away that something broke. Products may have been deleted by mistake and we only see it when a customer asks for them. Malicious code may have got in weeks ago and we only find it now. Not everything shows straight away: things have broken silently on my own site too, and I wrote about it in “I changed one setting and broke my own site. Without noticing”.
The usual advice is to keep a handful of recent backups. But if they are all from the last week and the damage happened two weeks ago, every one of them already contains it. You then have several perfect copies of a broken site. Ask how far back you can go, and whether that period covers a problem you were slow to spot.
6. When was it last tested, and who presses the button?
A backup that has never been restored is an assumption, not protection. I said it in the article on your site’s folder, and I will keep saying it as long as it needs saying.
Ask your provider for a restore test. It is not risky: the site is set up from the backup at a separate test address, and nobody touches the live one. You open it, look at the latest orders, try the contact form. And two things are written down: the date of the test and how long it took. That duration is the floor for question 2: the site will not be working again any faster than the test took.
Also get it in writing who does the restore when it is needed and whether it is charged. The difference between “I’ll take a look” and “I’ve got it” is a matter of contract, not of goodwill, as I wrote in “Four things you do not know about your own website, and should”. The day of the failure is not the time to negotiate it.
The day you need it
A backup is one of those things you pay for year after year without ever seeing. That is good: it means you never needed it. But it also means that, if you never test it, you will find out whether it works at the worst possible moment, the day you need it.
Six questions, one phone call and one test. That is all. And on that Monday, if it ever comes, “we have a backup” will finally mean what it sounds like.
If you do not know the answers to the six questions for your own site, that is where we come in: we check what backups exist, what they contain and where they are kept, and we run a restore test at a separate address without touching your live site. You get a written answer on how much work would be lost and how long it would take to get running again. In our maintenance and support plans, regular backups are part of the work, and stepping in when something breaks is our contractual obligation. Send us through the form your site address and who hosts it now.
The whole picture: this article covers one part of a larger subject. If you are after the whole of it, from beginning to end, it is in the guide to security and legal on your website.
