Is my site really backed up? The question to ask before a crash
A website backup is only useful if it can be restored. Frequency, separate copies, and testing: the vital questions to ask before a crash occurs.
Sur cette page5 sections
"Yes, normally, the host takes backups." This is an easy answer to accept as long as the site is working. The day you delete the wrong page, the word "normally" becomes much less comfortable.
The question isn't just whether a file with your site's name exists somewhere. You need to know what it contains, how old it is, and how to get the site running again with it. This is the difference between a reassuring clause in a contract and a truly useful backup.
They might still exist in the payment service or in received emails. You can sometimes reconstruct part of the work. But the restored site hasn't found them on its own, and someone now has to put the information back in order.
Backup frequency is chosen based on this: how much work are you prepared to redo? A week of changes on a rarely modified showcase site and a week of bookings do not have the same value.
A daily copy might suit some uses. For data arriving all day long, several frequent copies may be necessary. At Cadarsir, monitored sites are backed up several times a day. This provides more recent recovery points, without meaning that no data can ever be lost between two copies.
And before any major intervention, an additional recovery point is planned. It's easier to know where to go back to before making changes than to look for it afterwards.
If the copy contains the code but not the database, you might have the kitchen but nothing in the cupboards. If it contains the text but not the uploaded files, the pages return with missing images. Every site has its specificities; you must check what the backup actually includes.
You also need to keep several dates. Content deleted yesterday and discovered today is simple enough. An error that appeared two weeks ago and was copied every night is less so. The latest backup could very well contain the problem you are trying to fix.
Finally, if your site depends on a calendar or another external service, backing up the site doesn't automatically back up that service. You need to know where the important data is and who keeps a copy of it.
We therefore aim to separate copies from the main service and protect their access. For sensitive data, protecting the backup matters as much as protecting the site: it can contain the same customer information, just stored elsewhere.
La CNIL notably recommends separate copies, an isolated offline backup, and regular restoration tests. The specific choice depends on the environment. The idea remains understandable without being a system administrator: a single incident should not be able to wipe out all your recovery options.
The test is done in a separate environment. We get a copy running, then check more than just the homepage: images, admin access, forms, the booking process if there is one. We ensure this trial doesn't send real emails to customers or trigger real payments. The goal is to test recovery, not to create a second site acting in production.
This test sometimes reveals a missing access, a forgotten file, or an unforeseen dependency. That is exactly why it's useful. Discovering it on a quiet Tuesday is better than discovering it while your customers are trying to reach you.
After an incident, restoring isn't always enough. If the source of the problem is still present, you risk going through the same cycle again. We choose a healthy copy, address the cause, and reconcile recent operations where necessary.
Ces vérifications font partie d'un maintenance support. If all you have today is a "normally", we can start by taking stock. The expected result is simple: knowing what could be recovered tomorrow, and what would be left to rebuild.
The question isn't just whether a file with your site's name exists somewhere. You need to know what it contains, how old it is, and how to get the site running again with it. This is the difference between a reassuring clause in a contract and a truly useful backup.
Going back in time, yes, but how far?
Take a shop that recovers its site using Monday's backup. On Friday, after an incident, all the pages reappear. At first glance, everything is fine. Except that the orders recorded between Monday and Friday are not in that copy.They might still exist in the payment service or in received emails. You can sometimes reconstruct part of the work. But the restored site hasn't found them on its own, and someone now has to put the information back in order.
Backup frequency is chosen based on this: how much work are you prepared to redo? A week of changes on a rarely modified showcase site and a week of bookings do not have the same value.
A daily copy might suit some uses. For data arriving all day long, several frequent copies may be necessary. At Cadarsir, monitored sites are backed up several times a day. This provides more recent recovery points, without meaning that no data can ever be lost between two copies.
And before any major intervention, an additional recovery point is planned. It's easier to know where to go back to before making changes than to look for it afterwards.
Copying pages isn't enough to copy the site
A site isn't necessarily a folder you drag onto a USB stick. There are the files that make it work, the database containing the information, the images and documents added via the admin panel, and the settings needed to get everything running again.If the copy contains the code but not the database, you might have the kitchen but nothing in the cupboards. If it contains the text but not the uploaded files, the pages return with missing images. Every site has its specificities; you must check what the backup actually includes.
You also need to keep several dates. Content deleted yesterday and discovered today is simple enough. An error that appeared two weeks ago and was copied every night is less so. The latest backup could very well contain the problem you are trying to fix.
Finally, if your site depends on a calendar or another external service, backing up the site doesn't automatically back up that service. You need to know where the important data is and who keeps a copy of it.
The spare tyre doesn't stay in the car that's on fire
A backup kept only on the site's server can help after a mistake. But if the server disappears or if compromised access allows both to be deleted, the site and its copy go down together.We therefore aim to separate copies from the main service and protect their access. For sensitive data, protecting the backup matters as much as protecting the site: it can contain the same customer information, just stored elsewhere.
La CNIL notably recommends separate copies, an isolated offline backup, and regular restoration tests. The specific choice depends on the environment. The idea remains understandable without being a system administrator: a single incident should not be able to wipe out all your recovery options.
The green tick is a start, not the final test
The software says "backup successful". Great. Now, do we know how to restart the site with that backup?The test is done in a separate environment. We get a copy running, then check more than just the homepage: images, admin access, forms, the booking process if there is one. We ensure this trial doesn't send real emails to customers or trigger real payments. The goal is to test recovery, not to create a second site acting in production.
This test sometimes reveals a missing access, a forgotten file, or an unforeseen dependency. That is exactly why it's useful. Discovering it on a quiet Tuesday is better than discovering it while your customers are trying to reach you.
After an incident, restoring isn't always enough. If the source of the problem is still present, you risk going through the same cycle again. We choose a healthy copy, address the cause, and reconcile recent operations where necessary.
Four answers to get while everything is working
You can ask your provider these questions without getting into server details:- When was the last successful backup, and how many dates are kept?
- What does it contain, including data and documents added to the site?
- Where are the copies separate from the main server, and when was a restoration last tested?
- Who can intervene, with what access, and what is a realistic recovery time?
Ces vérifications font partie d'un maintenance support. If all you have today is a "normally", we can start by taking stock. The expected result is simple: knowing what could be recovered tomorrow, and what would be left to rebuild.
