Sauvegarder un site de fichiers : rotation, vérification et restauration

Toute entreprise disposant d'un site affirme avoir des sauvegardes. Beaucoup moins nombreuses sont celles qui ont déjà restauré, ne serait ce qu'une fois, pour vérifier que le dispositif fonctionne. Cette différence est l'ensemble du sujet : une sauvegarde n'a de valeur qu'au moment où elle est remise en service, et c'est précisément ce moment que personne ne répète. S'y ajoutent des questions moins visibles, ce que l'on copie exactement, combien de versions on garde, où elles résident et pendant combien de temps. Cet article passe en revue ces décisions, en insistant sur celles qui font la différence entre un dispositif rassurant et un dispositif efficace.

Définir le périmètre exact

La première erreur consiste à sauvegarder une partie de ce qui compose le site et à découvrir l'oubli au moment de la restauration. Un site n'est pas un dossier de fichiers : c'est un ensemble comprenant du code, une base de données, des fichiers téléversés, une configuration de serveur, des certificats, des tâches planifiées et des identifiants d'accès à des services tiers. Chacun de ces éléments peut être détruit indépendamment des autres, et l'absence d'un seul suffit à rendre la restauration incomplète. La notion générale est rappelée dans notre article sur la sauvegarde, sa définition et ses étapes.

Le code du site est en général la partie la mieux protégée, notamment lorsqu'il est versionné dans un dépôt distant. Cette protection est excellente et elle ne couvre pas les modifications faites directement sur le serveur, situation plus courante qu'on ne le voudrait. Un site dont le code vit dans un dépôt et dont personne ne touche aux fichiers en production est effectivement sauvegardé de ce côté. Un site dont un intervenant a corrigé un fichier en direct il y a six mois ne l'est pas, et cette correction disparaîtra lors du redéploiement. Un contrôle périodique comparant les fichiers du serveur à ceux du dépôt révèle ces écarts et il vaut la peine d'être automatisé sur les projets à plusieurs intervenants.

La base de données concentre l'essentiel de la valeur : contenus, commandes, comptes, réglages. Elle change en permanence sur un site actif, ce qui impose une fréquence de sauvegarde bien supérieure à celle des fichiers. Son export doit être cohérent, c'est à dire pris à un instant donné et non pendant que des écritures se produisent, faute de quoi les relations entre tables peuvent être incohérentes. Les outils prévus à cet effet gèrent ce point nativement, à condition d'être employés correctement. Un export produit par une extension travaillant depuis le navigateur s'interrompt fréquemment sur les bases volumineuses, ce qui rend les outils en ligne de commande nettement préférables dès que le site prend de l'ampleur.

Les fichiers téléversés forment le troisième pilier et ils sont irremplaçables : contrairement au code, ils ne se régénèrent pas. Sur un site alimenté depuis dix ans, ils représentent souvent plusieurs dizaines de gigaoctets et une valeur considérable. Leur volume les fait parfois exclure des sauvegardes quotidiennes pour des raisons de coût, arbitrage acceptable à condition d'être conscient. Une sauvegarde incrémentale, ne copiant que les nouveautés, règle généralement la question. Elle suppose en revanche que la chaîne complète des incréments reste disponible, une archive de base corrompue rendant inutilisables tous les incréments qui en dépendent.

Reste ce que personne ne pense à sauvegarder : la configuration du serveur, les règles de réécriture, les tâches planifiées, les enregistrements de zone du nom de domaine, les clés d'interface vers les services tiers. Ces éléments sont peu volumineux et leur reconstitution après un incident prend parfois plusieurs jours. Un simple document listant ces réglages, tenu à jour et conservé ailleurs, suffit à couvrir l'essentiel. C'est l'élément le plus rentable de tout le dispositif et le plus souvent absent. Sa rédaction demande deux heures et il transforme une reconstruction hasardeuse en suite d'étapes connues.

Choisir la fréquence

La fréquence se déduit d'une question précise : combien de temps de travail acceptez vous de perdre. Cette quantité, exprimée en heures ou en jours, détermine mécaniquement l'intervalle entre deux sauvegardes. Poser la question ainsi, plutôt qu'en termes de fréquence souhaitable, produit une réponse que la direction peut valider et qui engage un budget. Elle a aussi le mérite de sortir la discussion du terrain technique, où elle n'aboutit jamais, pour la porter sur celui du risque accepté.

Sur un site vitrine mis à jour deux fois par mois, une sauvegarde hebdomadaire perd au pire une modification, ce qui est parfaitement acceptable. Sur une boutique enregistrant quarante commandes par jour, perdre vingt quatre heures signifie perdre quarante commandes, avec des clients qui ont payé et dont la commande n'existe plus. La différence de traitement entre ces deux cas est évidente une fois posée en ces termes, et elle ne l'est pas du tout tant que le sujet reste technique. Chiffrer la perte en euros plutôt qu'en heures rend l'arbitrage immédiat pour une direction.

Le découplage entre fichiers et base est le réglage qui permet de concilier fréquence et coût. La base, peu volumineuse et très changeante, se sauvegarde plusieurs fois par jour sans difficulté. Les fichiers téléversés, volumineux et peu changeants, se sauvegardent quotidiennement en incrémental. Le code, versionné par ailleurs, ne demande qu'une copie de sécurité occasionnelle. Cette différenciation divise le coût par rapport à une sauvegarde complète quotidienne, tout en améliorant la protection sur ce qui compte. Il faut simplement veiller à ce que les deux jeux de sauvegardes restent cohérents entre eux, une base restaurée devant correspondre à des fichiers de la même époque.

Les périodes d'activité intense méritent un traitement particulier. Une boutique multipliant son volume pendant les fêtes doit augmenter sa fréquence de sauvegarde pendant cette période, la valeur d'une heure de commandes n'étant pas la même en novembre et en février. Cet ajustement temporaire est simple à mettre en place et il est rarement anticipé. Il mérite de figurer dans la liste de préparation des périodes commerciales, sujet abordé dans notre article sur la manière de déterminer la fréquence de sauvegarde d'un site WordPress.

Organiser la rotation

Conserver une seule sauvegarde, écrasée à chaque exécution, revient à n'en avoir aucune dès qu'un problème passe inaperçu quelques jours. Une corruption de base, une suppression accidentelle de contenus ou une intrusion se découvrent parfois une semaine après les faits, et la sauvegarde de la veille contient alors déjà le problème.

Le schéma classique conserve des sauvegardes quotidiennes sur trente jours, des sauvegardes hebdomadaires sur trois mois et des sauvegardes mensuelles sur un an. Cette pyramide offre une granularité fine sur le passé récent et une profondeur suffisante pour les découvertes tardives, pour un volume total raisonnable. Elle se configure une fois dans l'outil retenu et elle couvre la quasi totalité des situations rencontrées. Sur les sites soumis à des obligations de conservation particulières, une archive annuelle supplémentaire complète le schéma.

La règle des trois copies constitue le cadre de référence : trois exemplaires de la donnée, sur deux supports différents, dont un hors site. Appliquée à un site, elle signifie que la copie présente sur le serveur ne compte pas comme une sauvegarde, puisqu'un incident affectant le serveur les détruit toutes les deux. Cette évidence est ignorée par un nombre considérable de dispositifs, où les archives résident dans un sous répertoire du site lui même. Ces archives présentent en outre un risque supplémentaire : accessibles publiquement lorsque le répertoire n'est pas protégé, elles offrent à qui les trouve une copie complète de la base, identifiants compris.

L'externalisation doit aller jusqu'au bout de sa logique. Une sauvegarde stockée chez le même hébergeur, dans le même centre de données, protège contre une erreur humaine et pas contre un incident majeur ni contre une compromission du compte d'hébergement. Ce dernier cas est particulièrement instructif : un attaquant disposant des accès supprime en général les sauvegardes accessibles depuis le même compte. Un stockage chez un tiers, avec des identifiants distincts, est ce qui protège réellement. Le surcoût est modeste et il constitue probablement le meilleur euro dépensé de tout le dispositif.

La question de l'immuabilité mérite enfin d'être posée sur les sites à enjeu. Certains services de stockage permettent d'interdire la suppression d'une archive avant une date donnée, y compris par le compte qui l'a créée. Cette protection est la seule qui résiste à une compromission complète des accès. Elle coûte quelques euros par mois et elle change entièrement le niveau de protection contre les rançongiciels. Elle impose en contrepartie de bien dimensionner la durée d'immuabilité, puisqu'une archive verrouillée par erreur ne peut pas être supprimée pour libérer de l'espace.

Vérifier que les sauvegardes valent quelque chose

Un dispositif qui s'exécute sans erreur peut produire des archives inutilisables pendant des mois sans que personne ne le sache. Les modes de défaillance silencieuse sont nombreux et ils sont tous détectables par des contrôles simples.

Le premier contrôle porte sur l'exécution elle même : le travail s'est il lancé, s'est il terminé, combien de temps a t il pris. Une notification en cas d'échec ne suffit pas, car une tâche qui ne se lance plus n'échoue pas, elle est simplement absente. Il faut une alerte sur l'absence de sauvegarde depuis un certain délai, mécanisme inverse et bien plus fiable. C'est le contrôle le plus élémentaire et il manque dans la majorité des installations. Plusieurs services gratuits proposent ce type de surveillance par battement de cœur, le script signalant sa bonne exécution à chaque passage.

Le deuxième contrôle porte sur la taille des archives. Une sauvegarde de base qui pèse soudainement dix pour cent de sa taille habituelle signale un problème, même si l'opération s'est déclarée réussie. Une comparaison automatique avec la taille précédente, avec alerte au delà d'un écart de vingt pour cent, détecte ce cas. Ce contrôle prend quelques lignes de script et il attrape les défaillances les plus insidieuses. Une croissance anormale mérite la même attention, car elle signale parfois une table de journalisation devenue incontrôlable.

Le troisième contrôle porte sur l'intégrité du contenu. Une archive doit pouvoir être ouverte et son export de base doit se terminer par le marqueur attendu. Un export tronqué par un dépassement de mémoire ou une coupure réseau se restaure partiellement, ce qui est pire qu'un échec franc. Une vérification automatique du dernier fichier de l'archive tranche cette question en quelques secondes. Sur les archives compressées, l'outil de compression propose en général une option de test qui valide l'intégrité sans extraire le contenu.

Le quatrième contrôle est le seul qui compte vraiment : restaurer réellement. Une restauration complète sur un environnement séparé, menée au moins une fois par an, valide l'ensemble de la chaîne. Elle révèle systématiquement des éléments manquants que les contrôles précédents ne voient pas, un fichier de configuration oublié, une extension dont la licence est liée au domaine, une clé d'interface absente. C'est un exercice inconfortable et il est irremplaçable. Il constitue aussi la seule preuve défendable auprès d'un client ou d'un assureur que le dispositif fonctionne réellement.

Répéter la restauration

Restaurer sous la pression d'un incident, sans l'avoir jamais fait, garantit des erreurs et une durée bien supérieure à ce qui était annoncé. L'exercice de restauration a la même fonction qu'un exercice d'évacuation : il révèle ce qui ne fonctionne pas à un moment où cela n'a pas de conséquence.

La première répétition dure toujours plus longtemps que prévu, ce qui constitue déjà un enseignement. Le temps mesuré donne la durée réelle d'indisponibilité en cas d'incident, information que la direction a besoin de connaître et que personne ne peut donner autrement. Un délai de six heures annoncé et de deux jours constaté change la conversation sur le budget consacré au sujet. C'est souvent à ce moment que des investissements refusés pendant des années deviennent évidents.

L'exercice doit se dérouler sur un environnement distinct, jamais en écrasant la production. Un serveur temporaire, un conteneur local ou une machine virtuelle suffisent. Le critère de réussite est simple : le site fonctionne, on peut s'y connecter, les contenus récents sont présents, les images s'affichent. Chacune de ces vérifications échoue au moins une fois lors des premières répétitions. Noter chaque échec et sa correction transforme progressivement l'exercice en formalité.

Le résultat de l'exercice doit produire une procédure écrite, étape par étape, avec les commandes exactes et les emplacements des fichiers. Cette procédure permet à quelqu'un d'autre que son auteur de mener la restauration, ce qui est précisément le cas de figure à anticiper : l'incident survient rarement quand la bonne personne est disponible. Une procédure de deux pages, rangée à un endroit accessible sans le site, vaut mieux que toute la connaissance dans une seule tête. Une copie imprimée peut même se justifier sur les infrastructures critiques, un incident généralisé pouvant rendre inaccessibles les documents en ligne.

La répétition doit être inscrite au calendrier, une fois par an au minimum et après tout changement d'hébergement ou d'architecture. Sans cette inscription, elle n'est jamais faite, chacun ayant des tâches plus urgentes. Une demi journée par an constitue un coût dérisoire au regard de ce qu'elle protège. C'est la mesure qui distingue une entreprise qui a des sauvegardes d'une entreprise qui peut restaurer. La différence entre les deux ne se voit jamais, jusqu'au jour où elle devient la seule chose qui compte.

Automatiser proprement

Le dispositif doit tourner sans intervention et signaler ses défaillances, faute de quoi il se dégrade silencieusement au fil des mois.

L'automatisation la plus robuste repose sur une tâche planifiée au niveau du système plutôt que sur un mécanisme interne à l'application. Une tâche déclenchée par le passage des visiteurs, mécanisme employé par certains systèmes de gestion de contenu, ne s'exécute pas si personne ne visite le site, ce qui est exactement le cas d'un site en difficulté. La planification système ne dépend de rien d'autre que du serveur, comme nous le détaillons dans notre article sur la manière d'automatiser la sauvegarde d'un site avec un script Cron.

Le script doit être écrit pour échouer bruyamment. Une commande dont le résultat n'est pas vérifié peut échouer sans que le script ne s'arrête, produisant une archive incomplète et un rapport de succès. Vérifier chaque étape et interrompre au premier problème est la règle. Le script doit également écrire un journal daté, consultable après coup pour comprendre ce qui s'est passé. Ce journal doit lui même être conservé hors du serveur, faute de quoi il disparaît avec ce qu'il documentait.

Les identifiants employés pour accéder au stockage distant doivent être limités à ce seul usage, avec des droits d'écriture et non de suppression lorsque c'est possible. Un compte disposant de tous les droits, utilisé par un script présent sur le serveur, constitue exactement le vecteur qu'un attaquant recherche. Cette restriction est simple à mettre en place sur la plupart des services de stockage et elle est rarement appliquée.

Le chiffrement des archives s'impose dès qu'elles contiennent des données personnelles, ce qui est le cas de toute base de site comportant des comptes ou des commandes. La clé doit être conservée ailleurs que sur le serveur, faute de quoi le chiffrement ne protège que contre un vol de l'archive isolée. Cette question relève de la protection des données et nous ne sommes pas juristes : elle mérite d'être posée à un conseil compétent selon la nature des données concernées.

Reste la documentation, qui clôt le dispositif. Une page indiquant ce qui est sauvegardé, à quelle fréquence, où, avec quelle rétention, comment restaurer et qui contacter suffit. Elle doit être accessible sans le site, ce qui exclut de la ranger dans une page de l'administration. Sa dernière relecture doit être datée, afin de savoir si elle décrit encore la réalité. Sans elle, le dispositif dépend entièrement de la mémoire de celui qui l'a construit.