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

Your site is working this morning. Pages are loading, the contact form is responding and you have no particular reason to worry. But if everything disappeared this afternoon, would you be able to answer these questions: when was 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 enabled option, a truly usable copy and a site that can be restored quickly, there is a major difference. Unfortunately, this is often discovered at the worst possible time: after a mistake, a failed update, a crash 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 truly protect your business

Imagine a company that receives quote requests from its site every day. The last backup was on Monday. On Friday, an error damages the database — the part containing 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 business, 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 have to start by asking yourself: if an incident occurs now, how much work or data am I willing 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 should follow the real life of the site. The more it changes, the more frequent the copies should 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 need to find the database, images and documents added in the admin area, as well as the settings necessary for the site to function.

You also need to know the retention period. If a discreet error is discovered fifteen days after it appeared, a single backup dating from the day before risks having already recorded the problem. Keeping multiple versions allows you to return to a truly healthy state, not just 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 everything to be erased, the site and its "spare tyre" could 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 taking everything down.

The real test isn't the backup, it's the restoration

A dashboard can display a nice green tick every night. However, no one knows yet if the site will actually be able to restart using that 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 admin access. Until a restoration has been tested, protection relies partly on an assumption.

The test can be carried out 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 admin area and test important functions. For a classic SME or small business site, a periodic check and a new test after a major technical evolution already avoid many nasty surprises.

In other words, the question is not just "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 needs to intervene. When a site becomes inaccessible, stress easily leads to trying 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 isn't 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 clarifies responsibilities. The site owner knows who to call. The webmaster knows where to intervene. The host knows what falls under their service. No one wastes an hour looking for a password in an old inbox while the site remains unavailable.

Four questions to know where you stand today

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

• What is the date of the last successful backup and how often is it created?
• Are there multiple 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 person in charge — 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 restore point: major update, adding a feature, hosting migration or modification of the site structure. A backup just before the change doesn't replace the usual routine, but it offers a clear way back if the intervention goes wrong.

The right frequency is the one that matches 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 should be increased further so that a rollback doesn't delete a significant part of the business.

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

The essentials boil down to four ideas: an adapted frequency, a copy kept elsewhere, a tested restoration, organised web maintenance and a clearly responsible person. When these elements are known, backup stops being 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're not alone. This is exactly the right time to check — before needing 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 case of incident. The goal is not to drown you in technicalities, but to be able to answer a simple question clearly: if my site encounters a problem, are we ready?