Guides · Website · Backup
Website Backup: What Your Host Covers and What You Need to Keep Elsewhere
The copy your host includes can fix a recent mistake. To survive a lost account, ransomware or a service shutting down, add an independent copy and test restoring it.
The short answer
The backup included with web hosting is useful for undoing a recent mistake, but on its own it is not a backup policy. It is kept for a limited time, it may depend on the same account as the site, and the contract does not always guarantee that it works.
Keep at least one copy managed separately from your main hosting, and one copy that is offline or made immutable for the intended period. The 3-2-1 rule gives a simple benchmark: three copies of the data, on two different media, one of them offline. A copy sitting in the same customer account does not meet that last criterion.
Also define two needs with the business: how much data it can afford to lose, and the maximum time to get the service back. Finally, test a full restore of the files and the database. A backup that has never been restored is still a hypothesis.
Check the retention period and the contractual guarantee
The four plans reviewed include or describe very different mechanisms. Retention ranges from 14 to 90 days where it is specified, and some documentation states outright that long-term backup remains the customer’s responsibility. So read the contract and the documentation for the plan you actually bought, not just the “backup included” line on the sales page.
| Host | Retention available | What the contract or documentation says | Restore tested by the customer? |
|---|---|---|---|
| OVHcloud | 14 days (files), 30 days (database) | “It remains non-contractual […] it is your responsibility to put in place your own restore policy” | To verify |
| IONOS | 14 days, files and database alike | “You are therefore responsible for the long-term backup of your data” | To verify |
| o2switch | 30, 45 or 90 days depending on the plan | Self-service restore, but “destructive” — current data is replaced with no way back | To verify |
| LWS | To confirm in the plan you bought | “LWS is not required to back up the data hosted on the server” | To verify |
Also check whether the files and the database are copied at the same moment. At OVHcloud, for example, their retention periods differ. Restoring the database from one day and the files from another can create a state that never existed: missing orders, inconsistent accounts or missing media. A full restore must therefore pair compatible copies.
Keep the backup separate from the hosting account
An attacker often tries to delete or encrypt backups to prevent recovery. If the same account lets someone administer the site and erase its backups, the copy can disappear along with the main service.
An offline backup cannot be reached from the protected system. An immutable backup stays readable but cannot be modified or deleted for a set period. These protections are different; a robust policy can use both.
The backup offered in your host’s customer area stays useful for ordinary mistakes. But add a copy with separate authentication, separate admin rights and a separate location.
The OVHcloud fire shows the role of the contract
Overnight on March 9–10, 2021, the fire in OVHcloud’s SBG2 building in Strasbourg took about 3.6 million websites offline. Customers whose server and backup were both in the destroyed building, with no copy elsewhere, lost their data.
In one of the lawsuits that followed, the commercial court had awarded €101,102 to a company whose contract promised a backup at a geographically separate site. On appeal, OVHcloud’s breach was recognized, but the limitation-of-liability clause was applied: the compensation was reduced to €1,800.48, six months of subscription fees.
The lesson is twofold: check where the copy actually sits, and read the compensation cap. Even when a host’s breach is recognized, the contract can sharply limit the amount paid. An independent backup protects the data; compensation does not recreate it.
Export your data before the account closes
A host can delete the space and its backups a few weeks after a missed payment or as soon as certain plans are closed. Under the terms reviewed, o2switch announces 30 days after a missed payment and immediate destruction in case of early refund; OVHcloud announces 45 days after the due date.
Before any cancellation, export the files, the database, the hosted emails, the DNS settings, the certificates and any configuration you need. Restore that copy in a test environment, and only after validating it, close the old account.
What not to do
- Canceling before exporting and testing a complete copy
- Mistaking the closed space’s backups for an archive the company keeps itself
- Waiting until the end of the announced period to start a migration
- Assuming the new provider took over the emails, the DNS and the certificates as well as the site
Apply the 3-2-1 rule to your site
Keep three copies of the data: the data the site uses, and two backups. Place them on at least two distinct media or services, one copy being offline. ANSSI (France’s national cybersecurity agency) and the CNIL (France’s data protection authority) both adopt this principle as the basis of a backup policy.
For a website, a simple setup could be: the live site, an automatic backup in separate storage, and a periodic offline copy. The two backups must not be deletable with the hosting administration account alone.
See the technical detail: designing and testing your copies
Turn 3-2-1 into a real architecture
| Environment | Working copy | Second copy | Offline or immutable copy |
|---|---|---|---|
| Shared hosting | Live site and database | Automatic export to managed storage under a separate account | Periodic encrypted copy, disconnected after the export |
| Virtual server | Live volumes and database | Snapshots stored outside the server | Export to another account with deletion blocked for a set period, plus an offline copy depending on the risk |
| Cloud infrastructure | Live service and database | Backup in a separate backup account | Immutable storage and separate admin identities; offline copy for critical data |
| Online service with no server access | The service’s data | Automatic exports of the data and the configuration | Exports kept in storage independent of the provider |
Another region of the same provider protects against a local outage, but not necessarily against compromise of the main account. A separate account limits that risk without automatically becoming an offline copy. “Off-site,” “separate account,” “immutable” and “offline” describe four different protections; the policy must say which ones are really in place.
Define the acceptable loss and delay
State the business need without jargon:
- How many hours of new data can we afford to lose?
- How long can the site stay unavailable?
The first number sets the minimum backup frequency. The second sets the restore target, the resources needed and the order in which services come back. Your provider can then document them under the technical names recovery point objective and recovery time objective.
Test a full restore
Run the test in an isolated environment separate from the live site. It should cover:
- Retrieving the copy without using a session that is already open
- Restoring the files and the database in a coordinated way
- Starting the site with test secrets
- Opening pages, logging in to an account and displaying the media
- For a shop, a test order with no real payment
- Measuring the time taken and the data missing
- Securely deleting the test environment after validation
What the 3-2-1 formula does not decide
The formula was popularized in 2006 by Peter Krogh in The DAM Book, then adopted by ANSSI and the CNIL. It specifies a number of copies and their separation; it fixes neither their frequency, nor their retention period, nor the restore order. The 3-2-1-1-0 and 4-3-2 variants add other objectives, but they are not official French recommendations.
Separate backups from records kept by law
Article 32 of the GDPR requires you to be able to restore the availability of data after an incident and to regularly test the measures in place. An accidental loss of personal data can be a breach even without an attack.
Other laws require certain documents to be kept: ten years for accounting documents and supporting records, six years for invoices under the tax authority’s right of access (droit de communication), five years for payslips. This obligation applies to documents that remain available and usable, not to keeping every daily backup for that whole period.
Archiving keeps the reference versions for the legal period. Backup lets you recover them after a deletion, a failure or an attack. Plan both together, but they do not meet the same need.
| Document | Retention period | What backup must guarantee |
|---|---|---|
| Accounting documents and supporting records | 10 years | A recoverable copy of the archives still subject to this period |
| Invoices subject to the tax authority’s right of access | 6 years | A restore that preserves the document, its format and its link to the relevant financial year |
| Payslips kept by the employer | 5 years | A copy protected from accidental deletion and checked during tests |
Check that your backup is really usable
This short check does not replace a full, timed restore. It lets you quickly spot a backup that is unreachable, incomplete or dependent on the same account as the site.
- 0 to 5 minutes — Find the copy. Identify its location, its date, the account needed to reach it and the retention time remaining.
- 5 to 10 minutes — Check the scope. Confirm the copy contains the files, the database, the media and the configuration you need. For an online shop, also check the data that lives in external services.
- 10 to 20 minutes — Extract without overwriting. Restore a small set of files and open a database export in an isolated location. Do not use the destructive restore function on the live site.
- 20 to 25 minutes — Verify. Check that the files open, that the database export is readable and that the dates match the copy you were told about.
- 25 to 30 minutes — Record the result. Note what was tested, by whom, when, how long it took and what was missing. Then schedule a full restore in a test environment.
The 58% failure rate often quoted comes from a software vendor and a sample of large international companies. It should not be presented as an independent French statistic. The useful proof is still the dated result of your own restore.
Assess the data breach too
The loss or destruction of personal data can be a breach even without a hack. Document the data affected, the people concerned and the possible consequences. Then check whether the CNIL must be notified and which deadlines apply to the incident.
What to ask your host and your provider
Is the backup included in our plan guaranteed by the contract, and how many days does it stay available?
The exact clause, the retention period by type of data and any exclusions.
Are the files and the database copied at the same moment, and can they be restored together?
The times of the two copies and the method used to keep them consistent.
Can a person who controls the hosting account also delete all the backups?
Separate accounts, rights and deletion mechanisms, or a clear explanation of why there is no separation.
How many hours of data can we lose at most, and how fast must the whole site be back?
Two durations approved by the business: acceptable data loss and recovery time.
When was a full restore last tested, and what was the result?
A date, the scope restored, the time measured and the errors encountered.
What happens to our independent copy if we change hosts or the main account is suspended?
A location and access that stay available independently of the hosting contract.
Sources
- ANSSI — Sauvegarde des systèmes d’information, les fondamentaux (Information system backup: the fundamentals)
The 3-2-1 rule (R11), the essential offline backup (R12), restore testing (R22).
- ANSSI — Attaques par rançongiciels, tous concernés (Ransomware attacks: everyone is concerned)
Why a connected backup is a backup that can be encrypted.
- CNIL — Texte consolidé de l’article 32 du RGPD (Consolidated text of GDPR Article 32)
The three distinct obligations: availability, restoration, regular testing.
- CNIL — Définition d’une violation de données personnelles (Definition of a personal data breach)
Confirms that an accidental loss with no backup is a notifiable breach.
- Legalis.net — Jugement du tribunal de commerce de Lille Métropole, 26 janvier 2023 (Lille commercial court ruling, January 26, 2023)
Bâti Courtage v. OVH: the first-instance ruling awarding €101,102.
- LeMagIT — L’arrêt de la cour d’appel de Douai, 24 avril 2025 (Douai Court of Appeal ruling, April 24, 2025)
Compensation reduced to €1,800.48: the decision that is authoritative today.
- Légifrance — Code de commerce, art. L123-22 (Commercial Code)
The legal retention period for accounting documents: ten years.
- OVHcloud — Spécificités techniques des hébergements mutualisés (Technical specifics of shared hosting)
The exact wording on the included backup being non-contractual.
- IONOS — Sauvegarder manuellement l’espace web et les bases de données (Manually back up web space and databases)
The 14-day retention and the customer’s responsibility for long-term backup.
- o2switch — Comparatif de l’offre unique (Single-plan comparison)
Retention periods by plan variant: 30, 45 or 90 days.
- LWS — Conditions générales de vente 2024 (2024 terms of sale)
The exact clause: LWS is not required to back up server data.