Sauvegarde des données d’un site autonome : stratégie de sauvegarde et stockage hors site pour bases de données, fichiers et configurations
1. Pourquoi on ne peut pas se contenter de “sauvegarder tout le disque en un seul paquet”
Beaucoup de webmasters sauvegardent en “compressant tout le serveur chaque jour”. Cela semble prudent, mais pose trois problèmes.
Premièrement, le paquet complet est trop volumineux : une sauvegarde prend des heures et les sauvegardes incrémentielles ne peuvent pas être assez fines. Deuxièmement, la fréquence de changement des trois types d’actifs est radicalement différente : la base de données change toutes les heures, les fichiers changent occasionnellement, la configuration reste inchangée pendant des mois. Utiliser la même fréquence revient soit à gaspiller des ressources, soit à ne pas sauvegarder assez. Troisièmement, lors d’une restauration complète, on restaure aussi les fichiers inutiles et le code infecté par des chevaux de Troie, ce qui revient à restaurer l’incident avec.
Le jugement contre-intuitif est ici :La valeur d’une sauvegarde ne dépend pas de “ce qui a été sauvegardé”, mais de “peut-on restaurer, et à quelle vitesse”. J’ai vu trop de sites avec une “sauvegarde quotidienne” qui, le jour où le serveur est tombé, ont découvert que le fichier de sauvegarde était corrompu, que le mot de passe était introuvable et que la copie hors site n’avait jamais été transférée avec succès.
Le seul critère d’acceptation d’une stratégie de sauvegarde : prendre cette sauvegarde sur une machine neuve et voir si le site peut tourner en 4 heures. C’est aussi la raison pour laquelle Sauvegarde et restauration : s’entraîner à réagir met l’accent sur la “vérification de la restaurabilité”.
| Type d’actif | Contenu | Fréquence de changement | Conséquence d’une sauvegarde manquée |
|---|---|---|---|
| Base de données | Commandes, demandes de devis, utilisateurs, tables de contenu | Toutes les heures | Perte des transactions et des données clients |
| Document | Téléversements des utilisateurs, images, pièces jointes, médias | Quotidienne | Perte des pièces jointes et des images produits |
| Configuration / code | Thème, extensions, configuration Nginx, variables d’environnement | À chaque modification | Impossible de reproduire le site d’origine après réinstallation |
| Sauvegarde complète du disque | Tout ce qui précède plus les fichiers système inutiles | Quotidienne | Trop volumineux, trop lent, restauration infectée |
2. Sauvegarde de la base de données : complète plus incrémentielle, RPO limité à 1 heure
La base de données est l’actif le plus important des trois, et celui qu’on ne peut pas se permettre de perdre. La stratégie repose sur le couple « complet + incrémental » : chaque nuit, une sauvegarde logique complète (mysqldump ou outil équivalent), et avec le binlog activé, un incrément toutes les heures. Dans le pire des cas, on ne perd donc que la dernière heure de données : cet indicateur s’appelle le RPO (objectif de point de reprise).
Deux points de vigilance : premièrement, ne lancez pas la sauvegarde complète aux heures de forte activité, programmez-la entre 3 h et 5 h du matin ; deuxièmement, vérifiez l’intégrité des fichiers de sauvegarde, ne vous contentez pas de constater que « le fichier a bien été créé » — restaurez-en un échantillon dans une base temporaire pour le contrôler, sinon un fichier peut très bien être corrompu depuis une exécution donnée. Quand la base grossit, la sauvegarde logique ralentit : c’est le moment d’envisager une sauvegarde physique ou les sauvegardes automatiques intégrées à votre base de données cloud.
Exemple concret : À 4 h du matin, une table de commandes est supprimée par erreur. Procédure de restauration : on restaure d’abord la sauvegarde complète de la nuit précédente dans une base temporaire, puis on rejoue le binlog depuis 4 h jusqu’à l’incident, et la base revient à une minute avant l’incident. L’opération prend environ une heure, avec une perte réduite au minimum.
| Mode de sauvegarde | Fréquence | RPO | Étape concernée |
|---|---|---|---|
| Sauvegarde logique complète quotidienne | 1 fois par jour | Environ 24 heures | Moins de 5000 visites par jour |
| Complet + incrément binlog | Complet chaque jour, incrément chaque heure | ≤ 1 heure | Solution standard pour un site marchand |
| Sauvegarde automatique de la base cloud | Gérée par le fournisseur | Généralement en moins de 5 minutes | La solution sereine après le passage au cloud |
| Réplication maître-esclave en temps réel | Temps réel | proche de 0 | À ajouter en cas d’exigence de haute disponibilité |
3. Fichiers et configuration : sauvegardez-les à part, ne les mélangez pas avec la sauvegarde de la base
Les fichiers (pièces jointes des demandes envoyées par les utilisateurs, photos produits, médias) sont volumineux et changent lentement : ils n’ont pas leur place dans la sauvegarde quotidienne de la base. Utilisez un outil de synchronisation incrémentale dédié pour répliquer le répertoire d’upload vers un stockage objet distant, une fois par jour suffit. Pour la gestion des gros fichiers comme les images et les vidéos, voir Gouvernance des actifs médias.
La configuration et le code sont ce qu’on oublie le plus facilement. Beaucoup sauvegardent très bien leur base de données, mais oublient que la configuration Nginx, les versions des extensions et les variables d’environnement sont dispersées sur le serveur : après une réinstallation, plus personne ne sait comment le site tournait.
La bonne méthode : mettez tout le code et la configuration dans un dépôt Git, et stockez les variables d’environnement et les clés secrètes à part, dans un coffre-fort de mots de passe, hors de Git. La configuration n’est alors plus « sauvegardée » : chaque modification est versionnée, et vous pouvez revenir à n’importe quel état antérieur à tout moment.
| Actifs | Outil / mode de sauvegarde | Fréquence | Stockage distant |
|---|---|---|---|
| Base de données complète | Script automatique mysqldump | Chaque nuit | Stockage objet dans une autre région |
| Incrément de la base | Archivage du binlog | Chaque heure | Distant avec le complet |
| Fichiers envoyés par les utilisateurs | Synchronisation incrémentale vers le stockage objet | Quotidienne | Écriture directe sur le stockage distant |
| Code et configuration | Commit Git | À chaque modification | Dépôt distant dans le cloud |
| Variables d’environnement et clés | Coffre-fort de mots de passe | Enregistré à chaque modification | Conservé chiffré dans le cloud |
4. Stockage distant : comment appliquer la règle 3-2-1
La règle 3-2-1 est un classique de la sauvegarde, mais les équipes d’une seule personne n’en appliquent souvent que la moitié. Elle signifie en réalité : conserver 3 copies des données, sur 2 supports différents, dont 1 hors site. Le point clé du « hors site », ce n’est pas « un autre disque dur », mais « un autre endroit qui ne disparaîtra pas en même temps à cause du même incident ».
Concrètement, sur un serveur cloud : une copie récente sur le disque local (la plus rapide à restaurer), une copie dans le centre de données du serveur, et une copie envoyée vers un stockage objet dans une autre ville. Un snapshot de disque bloc dans le même compte et la même région ne compte pas comme un vrai hors site : incendie du centre de données ou compte verrouillé, et toutes ces copies disparaissent ensemble. Conservez la copie hors site au moins 30 jours, avec une archive mensuelle d’un semestre, pour éviter qu’un rançongiciel ne chiffre aussi les anciennes sauvegardes.
Exemple concret : Le serveur est chiffré par un rançongiciel. La sauvegarde locale et celle du serveur sont chiffrées, mais la copie d’il y a 30 jours dans le stockage objet de l’autre ville est hors ligne, hors de portée du logiciel de chiffrement. Vous restaurez cette copie sur une nouvelle machine : vous perdez au pire 30 jours de données, mais le site tient.
C’est tout l’intérêt de la copie hors site : elle n’est pas là pour restaurer plus vite, mais pour exister quand « toutes les copies en ligne ont disparu ». Pour la procédure de nettoyage après un piratage, voir Après un piratage de site.
| Emplacement de la copie | Support | Durée de conservation | Rôle |
|---|---|---|---|
| Disque local du serveur | Disque cloud | 7 derniers jours | Restauration rapide au quotidien |
| Stockage objet du même centre de données | Stockage objet | 30 derniers jours | Restauration en cas de panne serveur |
| Stockage objet hors site | Bucket d’une autre région | 30 jours + archive mensuelle | Sinistre au niveau du centre de données / du compte |
| Copie téléchargée en local | Disque personnel | Une copie par trimestre | Filet de sécurité quand le fournisseur lui-même n’est pas fiable |
5. Les pièges : les quatre fausses sécurités les plus courantes en matière de sauvegarde
Premier piège : « la sauvegarde est sur la même machine ». Stocker le fichier de sauvegarde dans un autre dossier du serveur : si le serveur tombe ou est supprimé, les deux copies disparaissent ensemble. La sauvegarde doit quitter cette machine. Deuxième piège : « ne jamais tester la restauration ». Le script affiche une sauvegarde réussie chaque jour, mais vous n’avez jamais réellement restauré — il est fort possible qu’une sauvegarde soit corrompue depuis six mois.
Troisième piège : « sauvegarder les données mais pas la configuration ». La base de données est restaurée, mais impossible de se rappeler quelle version du plugin était utilisée ni comment Nginx était configuré : le site ne redémarre toujours pas. Quatrième piège : « aucune alerte sur la sauvegarde ». Le script de sauvegarde est tombé en panne pendant trois semaines sans que personne ne le remarque, et on ne découvre qu’il était vide que le jour où il faut restaurer. Une tâche de sauvegarde doit déclencher une alerte en cas d’échec : deux jours consécutifs sans succès et vous êtes prévenu.
| Fausse sécurité | Symptôme visible | Vrai problème | Bonne pratique |
|---|---|---|---|
| Sauvegarde dans un autre dossier de la même machine | Un fichier de sauvegarde chaque jour | Tout disparaît si le serveur tombe | Stocker impérativement ailleurs |
| Ne jamais tester la restauration | Le script de sauvegarde affiche un succès | Le fichier de sauvegarde peut être corrompu | Un exercice de restauration par trimestre |
| Sauvegarder uniquement la base de données | La base de données est sauvegardée chaque jour | La configuration et le code sont éparpillés | Configuration dans Git, clés dans un coffre-fort |
| Aucune alerte sur la sauvegarde | Trois semaines de panne sans que personne ne le sache | La sauvegarde échoue en silence | Alerte après 2 jours d’échec consécutifs |
FAQ — Questions fréquentes
À quelle fréquence faut-il vraiment sauvegarder un site e-commerce ?
Dans le principe 3-2-1, à quelle distance commence le “hors site” ?
Pourquoi faire des tests de restauration, si le fichier de sauvegarde existe ?
Les snapshots automatiques du fournisseur cloud suffisent-ils ?
Faut-il sauvegarder les images et pièces jointes envoyées par les utilisateurs avec la base de données ?
Comment un script de sauvegarde sait-il qu’il a lâché sans prévenir ?
Pour conclure
La sauvegarde de données est le domaine où l’on se félicite le plus facilement : le script tourne, les fichiers sont stockés, tout semble sûr. Mais la seule vraie validation, c’est le jour où l’on restaure. Pour un site indépendant géré seul, séparez la sauvegarde des trois types d’actifs, conservez une copie hors site selon la règle 3-2-1 et faites un exercice de restauration chaque trimestre : cette routine se met en place en un après-midi, ensuite elle tourne toute seule chaque jour et vous jetez un œil aux alertes une fois par semaine.
Trois étapes concrètes : premièrement, une sauvegarde complète quotidienne de la base de données plus une incrémentale toutes les heures, avec un RPO cible d’une heure ; deuxièmement, séparez les fichiers de la configuration, synchronisez les fichiers chaque jour vers un stockage objet hors site et versionnez la configuration dans Git ; troisièmement, faites un exercice de restauration chaque trimestre en visant moins de 4 heures, et branchez une alerte en cas d’échec des tâches de sauvegarde.
Une fois ces trois étapes faites, face à une panne de serveur, vous passez de « j’espère que la sauvegarde est bonne » à « je sais que je peux remettre le site en ligne en une demi-journée ». Pour le rythme de maintenance, référez-vous au calendrier de maintenance du site et planifiez le tout ensemble.
Une phrase à retenir : sauvegarder, ce n’est pas copier des fichiers, c’est acheter à votre site une assurance « en cas de pépin, on repart de zéro » — une police dont on n’a jamais testé l’indemnisation ne vaut pas plus qu’un chiffon de papier.