Is my site really backed up? The question to ask before a breakdown

Your site is working this morning. The pages are displaying, the contact form is responding, and you have no particular reason to worry. But if everything disappeared this afternoon, would you know how to answer these questions: how old is the last backup, where is it located, and who can put the site back online?

Many owners think that "the host must surely take care of it". This is sometimes true, at least in part. But between an activated option, a truly usable copy, and a site that can be restored quickly, there is a significant difference. Unfortunately, this is often discovered at the worst possible time: after a mistake, a failed update, a breakdown, or a cybersecurity incident.

The good news is that you don't need to become a server expert. To know if your site is properly protected, you mainly need to get simple and verifiable answers.

An invisible backup doesn't really protect your business

Imagine a company that receives quote requests from its site every day. The last backup is from Monday. On Friday, an error damages the database — the part that contains the content and information recorded by the site. The restoration works, but it takes the site back four days.

The pages are back. However, some requests received since Monday may have disappeared. Technically, the site did have a backup. For the company, it simply wasn't frequent enough.

This is where the question of website backup frequency becomes concrete. It's not about choosing between "every day" and "every week" at random. You must start by asking yourself: if an incident occurs now, how much work or data can I afford to lose?

A showcase site that changes three times a year does not present the same risk as a shop, a booking calendar, or a site that receives several forms per day. For the former, a weekly backup may be consistent, provided one is also created before each major intervention. For the latter, a daily backup — or even several times a day depending on activity — becomes much more logical.

The frequency must follow the real life of the site. The more it changes, the closer the copies must be.

"My host does backups": great, but which ones?

This phrase is reassuring, but it leaves several gray areas regarding your web hosting. What exactly does the copy contain? Visible files are not always enough. You generally also need to find the database, images and documents added in the administration, as well as the settings necessary for the site to function.

You also need to know the retention period. If a subtle error is discovered fifteen days after it appeared, a single backup dating from the day before risks having already recorded the problem. Keeping several versions allows you to return to a truly healthy state, and not just to the most recent copy.

Finally, a copy stored only on the same server as the site remains vulnerable to the same incident. If the server becomes inaccessible or if compromised access allows the whole thing to be erased, the site and its "spare tyre" can disappear together. A serious backup must therefore exist in a separate space from the main server, with protected access.

This doesn't mean you need to multiply complicated tools. You simply need to avoid a single problem being able to take everything away.

The real test is not the backup, it's the restoration

A dashboard can display a nice green tick every night. Yet, no one knows yet if the site will actually be able to restart thanks to this copy.

A backup can be incomplete, corrupted, too old, or difficult to use with the current environment. It can also restore pages without restoring the form, booking, payment, or administration access. As long as a restoration has never been tested, protection relies partly on a guess.

The test can be performed on a separate environment, without touching the public site. The objective is concrete: put a copy back in motion, open the main pages, check the images, log into the administration, and try the important functions. For a classic SME site, a periodic check and a new test after a major technical evolution already avoid many bad surprises.

In other words, the question is not only "do we have a file?", but "are we capable of rebuilding the service with this file?".

The day the site goes down, who does what?

Even a good backup loses its value if no one knows where it is or who should intervene. When a site becomes inaccessible, stress easily pushes one to try several manipulations in a hurry. Some can worsen the problem or erase useful clues.

A recovery plan doesn't need to be a fifty-page technical document. For a small structure, it can fit into a clear sheet: who to notify, where to find backups and access, how to identify the last healthy copy, which functions to check after restoration, and how to inform the people concerned if the interruption lasts.

The important word is healthy. The most recent backup is not always the best. If it was created after a hack or after an error appeared, restoring it may put the problem back in place. Hence the value of keeping several dates and knowing what happened before clicking.

This organisation also allows for clear responsibilities. The site owner knows who to call. The webmaster knows where to intervene. The host knows what falls under their service. No one loses an hour searching for a password in an old email inbox while the site remains unavailable.

Four questions to know where you stand today

You don't need to wait for a breakdown to take stock. Ask your host, your webmaster, or your service provider:

• What is the date of the last successful backup and how often is it created?
• Are there several versions, including at least one copy separate from the main server?
• When was a full restoration last tested?
• Who intervenes in the event of an incident, with what access and within what realistic timeframe?

Precise answers — a date, a location, a retention period, a responsible person — are reassuring. Answers like "normally", "it's automatic" or "the host must have something" mainly indicate that a check is necessary.

Also take advantage of every sensitive operation to create a return point: major update, addition of a feature, hosting migration, or change to the site structure. A backup just before the change does not replace the usual routine, but it offers a clear step back if the intervention goes wrong.

The right frequency is the one that corresponds to what you refuse to lose

For a showcase site that is rarely modified, a weekly backup may be suitable. If content is added several times a week, a daily copy becomes more relevant. If the site records orders, bookings, or requests that have immediate value, the frequency must be increased further so that a rollback does not delete a significant part of the activity.

There is therefore no magic number. The right decision depends on the rhythm of the site, the acceptable loss, and the time during which the company can function without it. It also depends on the actual capacity to restore, because an unusable daily backup remains less protective than a slightly less frequent but proven and mastered procedure.

The essentials come down to four ideas: an adapted frequency, a copy kept elsewhere, a tested restoration, organized web maintenance, and a clearly responsible person. When these elements are known, backup ceases to be an obscure option in hosting. It becomes a real safety net for the business.

And your site, could it be put back online tomorrow?

If you don't know when your site was last backed up, you are not alone. This is precisely the right time to check — before you need the answer in an emergency.

Cadarsir can help you take stock of the real state of your backups: frequency, content of copies, separate storage, possibility of restoration, and organisation in the event of an incident. The goal is not to drown you in technicalities, but to be able to clearly answer a simple question: if my site encounters a problem, are we ready?