Sauvegarde d’un site autonome : complète ou incrémentale, fréquence, emplacement de stockage et test de restauration
1. Que sauvegarder : séparer la base de données et les fichiers
La sauvegarde d’un site autonome porte sur deux choses : la base de données et les fichiers. La base de données contient le wp_posts, wp_options, wp_users de WordPress ; les fichiers sont les images, les thèmes et le code des extensions dans wp-content/uploads. Ces deux ensembles n’évoluent pas à la même fréquence et ne se sauvegardent pas de la même façon : les mélanger pose problème.
Exportez la base de données avec mysqldump ou wp-cli, en ajoutant à chaque fois l’option –single-transaction pour éviter de verrouiller les tables et de perturber le site en ligne. Synchronisez les fichiers avec rsync en incrémental : ne copiez que ce qui a changé, pas la totalité à chaque fois. Un dossier wp-content de 10 Go met une dizaine de minutes à copier en entier, contre quelques secondes en incrémental.
| Élément à sauvegarder | Fréquence de changement | Outils conseillés | Mode de sauvegarde |
|---|---|---|---|
| Base de données MySQL | Peut changer toutes les heures | mysqldump ou xtrabackup | binlog en incrémental toutes les 4 heures, dump complet chaque jour |
| wp-content/uploads | Nouvelles images chaque semaine | rsync | Synchronisation incrémentale quotidienne |
| Code des thèmes et extensions | Quelques modifications par mois | git ou rsync | Gestion de versions, complète chaque mois |
| wp-config.php | Change très rarement | À stocker à part dans un gestionnaire de mots de passe | Sauvegarde à chaque modification |
| nginx/configuration du site | Quelques modifications par mois | Géré avec git | Sauvegarde à chaque modification |
Exemple concret : un site d’équipement industriel à l’export sous WordPress reçoit chaque jour 3 à 5 demandes de devis et 2 à 3 photos de produits. La base de données est exportée par un script toutes les 4 heures, les fichiers sont synchronisés en incrémental chaque nuit à 3 h vers un stockage objet hors site. Sur une semaine, les sauvegardes de la base occupent environ 500 Mo et les sauvegardes incrémentales des fichiers environ 200 Mo, pour un coût de stockage inférieur à 20 yuans par mois. Cette configuration est plus fiable que n’importe quelle extension de sauvegarde payante.
Comment écrire le script de sauvegarde, dans le même esprit que Stack technique crater l’automatisation de l’exploitation décrite ici : pas d’extension avec interface graphique, mais cron et scripts, avec une alerte en cas d’échec.
2. Fréquence et rétention : plus de sauvegardes ne veut pas dire mieux
Un constat contre-intuitif : plus on sauvegarde souvent, mieux c’est. Faux. Des sauvegardes trop fréquentes consomment énormément de stockage et d’E/S, et au moment de restaurer, c’est le chaos : face à une pile de sauvegardes quasi identiques, impossible de savoir laquelle est propre. La bonne fréquence dépend de la vitesse à laquelle votre activité évolue : la base de données toutes les 4 heures, car les demandes de devis peuvent arriver à tout moment ; les fichiers une fois par jour, car les images ne sont pas téléversées souvent.
La politique de rétention suit le modèle grand-père, père, fils : les sauvegardes quotidiennes sont conservées 30 jours, les hebdomadaires 12 semaines, les mensuelles 12 mois et les annuelles 3 ans. Vous pouvez ainsi restaurer un article supprimé par erreur hier, comme revenir à une version saine d’il y a six mois, avant le piratage.
| Type de sauvegarde | Fréquence | Durée de conservation | l’emplacement de stockage | Utilité |
|---|---|---|---|---|
| Base de données complète | Chaque jour à 3 h du matin | 30 jours | Stockage objet hors site | Restauration après suppression accidentelle |
| Incrémentale binlog de la base de données | Toutes les 4 heures | 7 jours | Local + hors site | Restauration à la minute près |
| Complète des fichiers | Chaque dimanche à l’aube | 12 semaines | Stockage objet hors site | Retour arrière hebdomadaire |
| Incrémentale rsync des fichiers | Chaque jour à l’aube | 30 jours | Stockage objet hors site | Retour arrière quotidien |
| Archivage mensuel | Le 1er de chaque mois | 12 mois | Archivage froid Glacier | Conformité mensuelle et long terme |
| Archivage annuel | Chaque janvier | 3 ans | Archivage froid Glacier | Audit annuel et historique |
Exemple concret : un site à l’international découvre le 15 mars à 14 h que sa base de données a été injectée avec du contenu malveillant. Grâce à la sauvegarde incrémentale binlog, la base peut être restaurée à midi le 15 mars, soit l’état d’avant l’attaque, avec seulement une demi-journée de demandes de devis perdue. Avec une sauvegarde complète quotidienne uniquement, la restauration remonterait au 15 mars à 3 h du matin, soit une journée entière de demandes perdue. C’est toute la différence entre un incrément toutes les 4 heures et une complète quotidienne.
Trois, l’emplacement de stockage : la règle 3-2-1, le hors site est obligatoire
La règle de sauvegarde 3-2-1 signifie : conserver 3 copies des données importantes, sur 2 supports différents, dont 1 hors site. Ce n’est pas de la théorie, c’est le fruit de d’innombrables incidents de rançongiciels. Dans les accidents réels, l’attaquant chiffre le serveur et les sauvegardes locales en même temps, car elles se trouvent sur la même machine que le site.
Comment choisir entre les trois niveaux de stockage : le premier, la sauvegarde locale, sur une autre partition du serveur, restaure le plus vite mais résiste le moins au risque ; le deuxième, le stockage objet hors site, avec AWS S3 ou Alibaba Cloud OSS, redondé entre zones de disponibilité, ne craint pas la panne d’un seul serveur ; le troisième, l’archivage froid, avec S3 Glacier ou OSS Archive, peu coûteux mais lent à restaurer, sert à la conformité annuelle et à la conservation à long terme.
| Niveau de stockage | Position | Vitesse de restauration | Coût | Usage principal |
|---|---|---|---|---|
| Sauvegarde sur disque local | Autre partition du serveur | Quelques secondes | 0 € | Restauration rapide au quotidien |
| Stockage objet hors site | S3/OSS interzones | Quelques minutes | Environ 0,02 €/Go/mois | Sauvegarde principale, synchronisation quotidienne |
| Archivage froid | Glacier/OSS Archive | De l’heure au jour | Environ 0,005 €/Go/mois | Conformité annuelle et long terme |
| Support hors ligne | Disque dur local/bande | Récupération physique du disque | Coût ponctuel du disque dur | Filet de sécurité en cas de rançongiciel extrême |
Rappel contre-intuitif : ne stockez jamais vos sauvegardes dans le répertoire web. Beaucoup de gens les placent dans wp-content/backup/ en pensant avoir une copie supplémentaire. En réalité, un attaquant qui tombe sur ce chemin les télécharge directement et récupère tous les noms de bases et de tables. La bonne pratique : placez les sauvegardes en dehors de la racine web, ou envoyez-les automatiquement vers un stockage objet et supprimez la copie locale. Pour la procédure de nettoyage après un piratage, voir Après un piratage de site.
et Accélération mondiale par CDN Attention à la combinaison : le cache CDN n’est pas une sauvegarde. Il ne fait que copier votre contenu statique sur des nœuds de périphérie ; si l’origine tombe, le cache CDN finira aussi par expirer. Ne considérez pas le cache CDN comme un plan de reprise après sinistre.
IV. Exercice de restauration : une fois par trimestre, vérifiez que vos sauvegardes sont réellement exploitables
L’élément le plus négligé d’une stratégie de sauvegarde, c’est l’exercice de restauration. Beaucoup d’entreprises font tourner leur script de sauvegarde pendant un an sans jamais avoir restauré quoi que ce soit. Le jour où le problème survient, elles découvrent que le fichier est corrompu, que le mot de passe de décompression est oublié, ou que la procédure de restauration ne fonctionne tout simplement pas. Dans les incidents réels, plus de 40 % des restaurations échouent, et les causes se répartissent en trois catégories.
Comment mener un exercice de restauration : chaque trimestre, choisissez une fenêtre de maintenance, récupérez la sauvegarde la plus récente depuis votre stockage objet hors site, restaurez-la sur un environnement de test tout neuf, et déroulez tout le processus : restauration des fichiers, import de la base de données, configuration de nginx, accès au site, vérification de l’envoi du formulaire de contact. Chronométrez l’ensemble et notez le RTO (objectif de temps de rétablissement) et le RPO (volume de données perdues) réels. Pour savoir comment définir concrètement le RTO/RPO, voir Reprise après sinistre d’un site indépendant et définition du RTO/RPO.
| Étapes de l’exercice | Action | Critères de validation | Points de défaillance courants |
|---|---|---|---|
| 1 Récupérer la sauvegarde | Télécharger la dernière sauvegarde complète + incrémentale depuis S3 | Téléchargement terminé en 5 minutes | Identifiants du stockage objet expirés |
| 2 Vérification de la décompression | Lister les fichiers avec tar -tzf | Nombre de fichiers complet, aucun fichier corrompu | Archive gzip corrompue, aucune vérification effectuée |
| 3 Restauration des fichiers | Décompresser dans le répertoire web de l’environnement de test | Permissions correctes 755/644 | Permissions perdues, site en page blanche |
| 4 Import de la base de données | mysql < backup.sql | Nombre de tables identique à la production | Jeu de caractères erroné, caractères chinois illisibles |
| 5 Configuration de nginx | Copier la configuration et changer le port | Le domaine est accessible | Règles de réécriture d’URL perdues |
| 6 Vérification fonctionnelle | Parcourir tout le processus d’envoi du formulaire de contact | E-mail reçu, enregistrement dans le CRM | Mot de passe SMTP codé en dur dans la configuration |
Exemple concret : une équipe n’avait pas fait d’exercice de restauration depuis six mois. Quand le disque du serveur a lâché, elle a récupéré la sauvegarde hors site, mais la décompression a échoué à mi-parcours : un paramètre gzip mal écrit dans le script de sauvegarde trois mois plus tôt avait produit deux mois de fichiers corrompus. Il a fallu restaurer une sauvegarde plus ancienne et propre, avec deux mois de contenu perdus. Un simple exercice de restauration trimestriel aurait permis de détecter le problème à l’avance.
Pour configurer la surveillance des sauvegardes, voir Surveillance et alertes du site: alerte WeCom en cas d’échec d’une tâche de sauvegarde, alerte si la taille du fichier de sauvegarde chute brutalement, alerte si la sauvegarde date de plus de 24 heures. Pour la liste de maintenance quotidienne, voir Les six tâches mensuelles de la maintenance d’un site.
FAQ — Questions fréquentes
Quel plugin utiliser pour sauvegarder un site indépendant ? UpdraftPlus suffit-il ?
Quelle fréquence de sauvegarde choisir, faut-il sauvegarder toutes les heures ?
Comment appliquer concrètement la règle de sauvegarde 3-2-1 ?
Comment organiser les tests de restauration, à quelle fréquence ?
Faut-il chiffrer les fichiers de sauvegarde, et comment stocker les clés ?
Comment savoir qu’un script de sauvegarde a échoué, et comment être alerté ?
Pour conclure
En matière de sauvegarde, la pire erreur est de croire qu’installer une extension suffit. L’extension s’exécute chaque jour, un fichier de sauvegarde est produit chaque jour, mais aucune restauration n’a jamais été testée : le jour où le problème survient, on découvre que la sauvegarde est corrompue, que la clé est perdue et que la procédure ne fonctionne pas. Une stratégie de sauvegarde, c’est moitié comment stocker, moitié comment restaurer, et cette seconde moitié compte dix fois plus.
Trois étapes pour passer à l’action : premièrement, mettre en place les trois niveaux de sauvegarde selon le principe 3-2-1, avec une copie locale, une copie sur stockage objet distant et une copie d’archivage à froid ; deuxièmement, définir la fréquence et la politique de rétention, avec des incréments de base de données toutes les 4 heures plus un complet quotidien, des incréments de fichiers quotidiens, et une rétention de 30 jours à 3 ans ; troisièmement, réaliser un exercice de restauration chaque trimestre, en déroulant toute la procédure dans un environnement de test et en notant le RTO et le RPO réels. Une fois ces trois étapes faites, vous pouvez dire que vous avez des sauvegardes.
Une phrase à retenir : une sauvegarde jamais restaurée équivaut à aucune sauvegarde. Un script qui tourne pendant un an ne vaut pas un seul exercice de restauration complet, car dans 40 % des incidents réels, les sauvegardes sont inutilisables au moment critique.