Sauvegardes d’un site ou d’une application : la règle 3-2-1

Une sauvegarde utile suit une règle simple, dite « 3-2-1 » : trois exemplaires de vos données, sur deux supports ou services différents, dont un conservé dans un lieu distinct de l’original. Mais la règle ne suffit pas : une sauvegarde qui n’a jamais été restaurée est une hypothèse, pas une protection. L’essentiel pour une PME est de savoir ce qui est sauvegardé, où, pour combien de temps, et de vérifier régulièrement qu’on sait le remettre en service.

Ce guide présente une méthode pratique pour un site ou une application. Il ne garantit ni l’absence de perte ni un délai de restauration : ces points se définissent par écrit avec votre prestataire. Notre page DevOps et hébergement décrit l’accompagnement que nous proposons sur l’exploitation et la reprise.

Que signifie la règle 3-2-1 ?

La règle 3-2-1 est une convention largement diffusée dans la profession, dont la formulation varie selon les sources. Elle se lit ainsi :

• 3 copies : l’original en production et deux sauvegardes.
• 2 supports ou services différents : une panne ou une erreur de configuration ne doit pas pouvoir toucher les deux.
• 1 copie hors site : conservée ailleurs que là où se trouvent les données d’origine.

Les recommandations officielles françaises vont dans le même sens sans employer ce nom. Cybermalveillance.gouv.fr conseille de réaliser plusieurs sauvegardes sur des supports différents, d’en conserver une dans un lieu distinct de celui des données d’origine, de déconnecter le support de sauvegarde lorsqu’il n’est pas utilisé et de vérifier régulièrement que la sauvegarde fonctionne (Pourquoi et comment bien gérer ses sauvegardes ?).

Une précision importante : plusieurs copies stockées chez le même fournisseur, avec les mêmes identifiants, restent exposées au même incident. Un compte administrateur compromis peut effacer l’original et ses sauvegardes si elles sont accessibles avec les mêmes droits.

Que faut-il sauvegarder pour un site ou une application ?

Faites l’inventaire de ce qui change et ne peut pas être recréé facilement :

• la base de données : comptes, commandes, demandes de contact, contenus saisis ;
• les fichiers téléversés : images, documents, pièces jointes ;
• la configuration : variables d’environnement, paramètres d’hébergement, règles de redirection, certificats si vous les gérez ;
• le code, s’il n’existe pas déjà dans un dépôt versionné et accessible ;
• les accès et la documentation de reprise, conservés séparément.

Un point souvent oublié : les services tiers. Un outil de messagerie, une plateforme de paiement ou un service de réservation conservent des données que votre sauvegarde ne couvre pas. Notez ce qui peut être exporté, selon quelle fréquence, et ce qui dépend entièrement du fournisseur. Notre article sur la maintenance d’un site propose une fiche d’inventaire à adapter.

Comment choisir la fréquence et la durée de conservation ?

Deux questions structurent le choix :

1. Combien de données récentes pouvez-vous accepter de perdre ? Un site de présentation qui change deux fois par an n’a pas les mêmes besoins qu’une application qui enregistre des commandes toute la journée. Cet objectif est parfois appelé RPO (perte de données maximale acceptable).
2. Combien de temps pouvez-vous rester sans le service ? C’est l’objectif de rétablissement, parfois appelé RTO.

Ces objectifs sont des cibles de conception, pas des garanties. Ils servent à choisir une fréquence de sauvegarde, un mode de restauration et un budget cohérents. Écrivez-les avec le prestataire, puis mesurez-les lors d’un exercice.

La durée de conservation doit aussi tenir compte de la détection tardive : une erreur ou une compromission peut être découverte plusieurs jours après. Si vous ne gardez que la dernière copie, elle peut déjà contenir le problème. Conservez donc plusieurs points de restauration étalés dans le temps.

Enfin, si les sauvegardes contiennent des données personnelles, elles relèvent du RGPD : elles doivent être protégées, leur durée de conservation justifiée, et les suppressions demandées par les personnes doivent être traitées de façon cohérente. La CNIL recommande des copies protégées, isolées des systèmes exploités, et des tests réguliers d’intégrité et de restauration (CNIL, Sauvegarder).

Comment protéger les sauvegardes elles-mêmes ?

Une sauvegarde est une copie complète de vos données : elle mérite au moins le niveau de protection de l’original.

• Accès restreint : peu de personnes peuvent lire ou supprimer les copies, avec des comptes nominatifs.
• Séparation des droits : le compte qui exploite le site ne devrait pas pouvoir effacer toutes les sauvegardes.
• Chiffrement adapté, avec une gestion des clés prévue : une sauvegarde chiffrée dont la clé est perdue est inutilisable.
• Copie déconnectée ou protégée en écriture, lorsque le service le permet, pour résister à un effacement volontaire ou à un logiciel malveillant.
• Journalisation des accès et des restaurations.

Pour les dispositifs proposés par un hébergeur, lisez la documentation : le périmètre (base seule ou fichiers aussi), la fréquence, la durée de rétention et le lieu de stockage sont parfois limités selon l’offre.

Comment tester une restauration, pas à pas ?

Le test de restauration est la partie qui distingue une sauvegarde d’une promesse. Planifiez-le au moins à chaque changement important de l’infrastructure, puis à intervalle régulier.

1. Choisissez une copie au hasard, pas forcément la plus récente.
2. Restaurez-la dans un environnement séparé, jamais par-dessus la production.
3. Vérifiez l’intégrité : la base s’ouvre, les fichiers sont lisibles, les tailles sont plausibles.
4. Testez un parcours représentatif : connexion, consultation d’une fiche, affichage d’une image téléversée. Désactivez les envois de courriels et les paiements réels.
5. Notez les résultats : copie utilisée, date des données restaurées, éléments manquants, temps observé, personnes impliquées.
6. Corrigez la procédure ou la sauvegarde et programmez le prochain essai.

Le temps mesuré pendant un exercice informe sur votre capacité à rétablir le service, mais il ne vaut pas engagement pour tous les incidents futurs. Protégez l’environnement de test : il contient les mêmes données que la production.

Qui est responsable de quoi avec un prestataire ?

Clarifiez les rôles avant l’incident. Dans un contrat, vérifiez au minimum : qui configure les sauvegardes, qui les surveille et reçoit les alertes d’échec, qui déclenche une restauration, dans quels délais le prestataire intervient et ce qui est facturé en supplément. Vérifiez aussi la propriété des accès : le compte d’hébergement et le dépôt de code doivent appartenir à l’entreprise. Pour la surveillance des échecs de sauvegarde, voir notre article sur la supervision et les alertes.

Exemple fictif : une boutique en ligne et ses images

Cet exemple est fictif et ne décrit ni un client ni un résultat mesuré.

Une petite boutique en ligne dispose d’une sauvegarde quotidienne de sa base, stockée chez son hébergeur. En préparant un exercice de restauration, elle constate que les images produits téléversées ne sont pas incluses. Elle ajoute leur copie vers un second service, avec des identifiants distincts, conserve plusieurs points de restauration et note la procédure dans un document de reprise. Elle programme un test dans un environnement séparé avant chaque changement important. Dans cet exemple, la valeur vient de la découverte d’une lacune avant l’incident, pas d’un résultat chiffré.

FAQ

Le plan de sauvegarde de mon hébergeur suffit-il ?

Cela dépend de son périmètre, de sa rétention et de l’indépendance de la copie. Vérifiez ce qui est couvert, où c’est stocké et qui peut le restaurer ; ajoutez une copie séparée si le risque le justifie.

Combien de temps faut-il conserver les sauvegardes ?

Il n’existe pas de durée unique. Elle dépend de votre besoin de revenir en arrière, de la détection tardive des erreurs et de vos obligations, notamment pour les données personnelles.

Un export manuel de temps en temps est-il acceptable ?

Pour un site qui change très peu, peut-être. Dès que des données arrivent régulièrement, une procédure automatisée et surveillée est préférable, car un export oublié ne protège de rien.

Conclusion

Une bonne stratégie de sauvegarde tient en quelques questions : que sauvegarder, où, pendant combien de temps, qui y accède, et a-t-on déjà restauré avec succès ? Commencez par l’inventaire et un premier test de restauration. Pour cadrer cela avec votre site ou votre application, consultez notre page DevOps et hébergement, notre offre de maintenance et sécurité ou contactez-nous.