Mon serveur a planté… et comment prendre une bonne copie de sécurité

Mon serveur a planté mercredi dernier, le 8 juillet 2015. Je vais me rappeler de cette date comme celle à laquelle j'ai eu une bonne leçon... et qui m'a poussée à réviser ma stratégie de copie de sécurité.

▼Publicité

Une histoire vécue

Ce serveur est celui que j'utilise pour publier mes notes de cours à mes étudiants à l'aide de la plateforme que j'ai programmée : Apical. Je l'utilise également pour héberger mon blogue ainsi que certains projets d'étudiants. Il était aussi temporairement utilisé pour héberger une application Web que je suis en train de développer pour mon employeur.

Bon, le serveur ne fonctionne plus alors je vais devoir remonter mes sites Web sur un autre serveur. C'est plate mais ça fait partie de la vie...

Mon premier réflexe est de contacter les techniciens en charge du serveur pour leur demander les fichiers de mes bases de données. C'est tout ce dont j'ai besoin car du côté programmation, j'ai une copie locale de tous mes fichiers. Ils me répondent que non seulement le serveur est planté mais en plus, le disque dur est complètement mort. Fini, kaput, quand on essaie d'en voir le contenu, on n'y voit que du blanc.

Ok, alors j'aurai un peu plus de travail pour remettre le tout en état. Je leur demande une copie des fichiers tirés du dernier backup et là, j'ai reçu une décharge électrique : ils ne faisaient plus de backup de mon serveur depuis un an. QUOI ???

Je ne veux pas relater ici la suite d'événements qui ont fait en sorte que le serveur n'ait plus de copie de sécurité. Je ne veux pas non plus entrer dans le processus malsain de recherche de coupable. Il faut passer en mode solution sinon, on ne s'en sort pas. Concentrons-nous sur les faits : le serveur est mort; le disque est inutilisable; il n'y a pas de copie de sécurité des données; je dois absolument remonter les sites Web qui étaient hébergés sur ce serveur.

Heureusement, j'ai moi-même un backup local mais il date de deux mois. Je pourrai donc reconstruire une partie des contenus de mes sites Web. Il y a même quelques éléments plus récents que je pourrai reconstruire à partir de données stockées dans des fichiers Word. Je n'ai donc pas tout perdu mais j'ai beaucoup de travail devant moi.

Les leçons que je tire de cet événement

Le plus important, je crois, dans une telle situation est d'en tirer une leçon afin d'éviter que ça se reproduise. Voici donc ce que je retiens :

  • Tout d'abord, IL NE FAUT JAMAIS SE FIER SUR LES COPIES DE SÉCURITÉ QUE D'AUTRES PERSONNES SONT SUPPOSÉES FAIRE DE NOS DONNÉES. Il faut absolument mettre en place une stratégie de copie de sécurité que nous utiliserons nous-même de façon régulière. Ici, je dois prendre tout le blâme : j'avais une stratégie de copie de sécurité mais elle était incomplète car je me fiais sur les copies de sécurité effectuées par les techniciens.
  • Ensuite, lorsque nous avons la chance de faire affaire avec un service informatique qui se charge des copies de sécurité, il faut s'assurer que les canaux de communication soient efficaces. Les techniciens doivent être conscients de l'importance du serveur et des conséquences si les données étaient perdues. Dans mon cas, ce n'était pas juste une bébelle sur laquelle je faisais des tests mais un vrai serveur en production. Si vous faites plutôt affaire avec un hébergeur, il faudra vérifier si sa politique de copie de sécurité et de temps de reconstruction correspond à vos besoins. Dans tous les cas, il faut également vérifier régulièrement si les copies ont bel et bien été réalisées (ex : recevoir un courriel de confirmation quand la copie de sécurité a lieu).

Copie de sécurité 101 : quoi, quand, comment, où ?

Voici un rappel des notions théoriques de base sur les copies de sécurité :

  • Les données doivent être présentes en tout temps sur deux supports physiques différents (ex : sur le disque dur du serveur et sur un disque dur externe).
  • La copie de sécurité doit être conservée à un endroit suffisamment éloigné des données originales pour ne pas être détruite en même temps que les données originales en cas de sinistre (ex : vol, incendie). Il y a une dizaine d'années, une amie à moi a perdu toutes les photos des trois premières année de vie de son fils parce que sa copie de sécurité était effectuée sur un CD qu'elle laissait toujours dans le lecteur. Elle a tout perdu lorsqu'elle s'est fait voler son ordinateur... et sa copie de sécurité.
  • Le support utilisé pour stocker la copie de sécurité doit être fiable. À éviter : les clés USB qui peuvent devenir inutilisables trop facilement. Parmi les supports intéressants, notons le cloud, le disque dur externe ou encore un second ordinateur.
  • Lorsqu'une copie de sécurité est effectuée, il faut toujours tester son contenu pour s'assurer qu'elle pourra être utilisée en cas de besoin. Une autre de mes amies faisait religieusement la copie de sécurité des données de son entreprise et après un crash de son ordinateur, elle n'a rien pu recouvrer puisque ses sauvegardes n'étaient pas bonnes dû à une erreur dans la configuration dans son logiciel de copie de sécurité.
  • Il faut déterminer quels fichiers doivent faire partie de la copie de sécurité. Généralement, les programmes peuvent être retrouvés facilement. On ne les prendra donc pas en backup. Quand aux fichiers de données, on pourra avoir une stratégie pour ceux qui sont modifiés régulièrement (ex : une base de données) et une autre pour ceux qui sont rarement modifiés (ex : les photos prises il y a un an ou encore un document Word contenant des procédures).
  • Il existe différents types de copie de sécurité : complète, incrémentale, différentielle ou encore miroir. La copie complète, comme son nom l'indique, prendra en backup tous les fichiers spécifiés. La copie différentielle ne prendra que les fichiers modifiés depuis la dernière copie complète. La copie incrémentale, quant à elle, ne prendra que les fichiers modifiés dans la journée ou, selon le logiciel utilisé, les fichiers modifiés depuis la dernière copie incrémentale. La dernière catégorie, la copie miroir, se chargera d'effectuer une copie de sécurité de tout ce qui n'est pas déjà sur la copie de sécurité.
  • La copie de sécurité peut générer une seul fichier qui sera une compilation de tous les fichiers touchés. On aura besoin du programme de copie de sécurité pour récupérer les fichiers en cas de besoin. Il est aussi possible de faire une copie de sécurité qui conservera une copie de chacun des fichiers touchés dans un dossier spécifique.
  • Idéalement, la copie de sécurité devrait avoir lieu dès que des fichiers sont modifiés. Dans la pratique, on prendra plutôt une copie de sécurité quotidienne si des fichiers critiques ont été modifiés ou encore une copie hebdomadaire. Certains préféreront même une copie mensuelle lorsque peu de fichiers ont été modifiés.
  • Lorsqu'on fait une nouvelle copie de sécurité, il faut s'assurer que la copie précédente soit encore disponible (historique). Ceci est arrivé à ma soeur : elle a par erreur effacé toutes ses données de son disque. Lorsque sa copie de sécurité a été réalisée, son logiciel de copie s'est chargé de créer une copie identique au contenu de son disque. Il a donc créé une copie vide et n'a conservé aucune trace de sa copie de sécurité précédente. Résultat : ma soeur a tout perdu.
  • Il est possible d'effectuer une copie manuelle des fichiers qui doivent être conservés en backup. Il existe également une foule de logiciels spécialisés. Il faut cependant choisir celui qui répondra à nos besoins. Voici quelques suggestions (pour Windows) :
    • Vice versa pro : c'est mon préféré. Il s'agit d'un shareware qui permet de créer une copie miroir de mes données. J'ai donc en tout temps, sur mon disque externe, une réplication exacte de tous les fichiers que je désirais conserver en copie de sécurité. De plus, il permet de conserver dans un dossier d'historique une copie datée de chacun des fichiers que j'ai modifiés ou effacés. Je suis donc protégée en cas où un fichier deviendrait corrompu ou en cas où j'effacerais un fichier par erreur.
    • Syncback SE : c'est mon second favori. C'est également un shareware. Il offre sensiblement les mêmes fonctionnalités que Vice versa pro, avec une interface différente.
    • FBackup : ce logiciel de sauvegarde est tout à fait gratuit. Il offre cependant moins de fonctionnalités. Celle qui me manque le plus est la possibilité de conserver un historique. Son grand frère, Backup4All, offre des fonctionnalités plus complètes.

Ma nouvelle stratégie de copie de sécurité

J'ai une stratégie de sauvegarde plutôt élaborée pour couvrir l'ensemble des sites hébergés sur mon serveur. Je vous partage ici celle concernant mon blogue, qui est un site WordPress, que j'ai temporairement installé chez un hébergeur.

  • Tout d'abord, j'installe une extension qui automatisera la copie de sécurité. Il n'y a rien comme l'automatisation pour prévenir la paresse ou les erreurs humaines. Mais pourquoi n'avais-je pas déjà réalisé cette étape ? Je l'ai pourtant fait pour les sites WordPress de mes clients... cordonnière mal chaussée ! Je choisis l'extension Updraft Plus qui est très intéressante et gratuite. Il s'agit de l'extension de backup la mieux cotée sur wordpress.org. Elle permet de déterminer un intervalle de sauvegarde pour la base de données et un intervalle différent pour un bloc comprenant les extensions, thèmes et fichiers envoyés (uploads). Je choisis donc de sauvegarder la base de données hebdomadairement et de sauvegarder le reste mensuellement. Fait intéressant : Updraft Plus ne sauvegarde pas le noyau de WordPress, ce qui est une bonne chose puisqu'il est toujours possible de le retrouver sur wordpress.org. De plus, il est possible de conserver un historique des sauvegardes. Je choisis de conserver la sauvegarde sur DropBox. J'aurais aussi pu utiliser Google Drive, OneDrive, etc. Je demande également à recevoir un courriel de confirmation quand la sauvegarde a lieu.
  • Comme j'ai été échaudée par le crash de mon serveur, je ne laisse rien au hasard et je choisis de renforcer ma stratégie de sauvegarde par les étapes manuelles suivantes.
  • Lorsque je modifie les fichiers PHP ou CSS pour modifier les fonctionnalités ou l'apparence de mon blogue, je travaille toujours localement. Ces fichiers font donc automatiquement partie du backup miroir quotidien de mon ordinateur que je réalise avec Vice versa pro sur mon disque externe. Et comme toute ma programmation est pour moi un enjeu critique, je conserve également une copie datée de mon dossier de programmation sur Dropbox à l'aide d'un fichier batch que je tourne à chaque fois que je termine une journée de programmation. Ceci assure que le backup et les fichiers originaux ne soient pas tous deux seulement sur des disques situés dans ma maison.
  • À chaque fois que je publie un article (généralement, une fois par semaine), je prend une copie de sécurité de la base de données. C'est cette étape que je ne réalisais pas avant le crash de mon serveur. Je me rends donc chez mon nouvel hébergeur, je choisis « Gérer la base de données » / « Gérer MySQL » puis je choisis l'action « Sauvegarde de la base de données ». Je prends soin de donner un nom contenant la date du jour au fichier de sauvegarde puis je télécharge ce fichier sur sur mon poste local (la date du jour dans le nom du fichier permettra de conserver un historique).

    Sauvegarde de la base de données chez SmarterASP

  • Aussi, à chaque publication d'article, je dois conserver les images associées à l'article. Puisque WordPress conserve les images dans un dossier au format wp-content\uploads\année\mois, je prends une copie de sécurité de tous les fichiers présents dans le dossier du mois. Il est à noter que si je n'avais choisis que la sauvegarde avec Updraft Plus, les images publiées hebdomadairement avec mes articles n'auraient été sauvegardées qu'une fois par mois...
  • À chaque fois que j'effectue une mise à jour de WordPress, je conserve une copie de tous les fichiers ainsi que de la base de données, le tout dans un fichier .zip daté (c'est cette stratégie qui m'a sauvé la vie puisque j'avais fait une mise à jour de WordPress il y a deux mois).

Au final, en plus de la sauvegarde automatique sur DropBox, j'obtiens un dossier que j'ai nommé BackupBlogueChristiane qui contient des fichiers au format suivant :

Contenu du dossier de backup WordPress

Si jamais un nouveau crash avait lieu, je pourrais reconstruire le tout à partir du dernier zip, auquel j'ajouterais la dernière base de données ainsi que toutes les images ajoutées depuis le dernier zip.

La reconstruction de mon blogue

Dans cette aventure, j'ai perdu exactement 11 articles dont un ou deux pour lesquels je n'ai aucune autre copie. Je vais tenter de reconstruire le tout afin de remettre en place le travail que j'avais réalisé dans les deux derniers mois.

Vous m'excuserez donc, si vous êtes abonnés à mon blogue, de vous envoyer des avis de publication d'articles que vous avez déjà lus. Merci de votre compréhension.

Je crois donc qu'une fois ce travail réalisé, mon blogue aura repris son apparence d'avant le crash, à l'exception des précieux commentaires de mes lecteurs pour lesquels la reconstruction serait plutôt difficile.

Alors, merci de continuer de me supporter et soyez assurés que si un nouveau crash survenait, je serais mieux préparée.

Et vous ???

Pour plus d'information

« Why backups are important ». PluralSight. http://blog.pluralsight.com/data-backups-important

« 7 Best WordPress Backup Plugins Compared (Pros and Cons) ». wpbeginner. http://www.wpbeginner.com/plugins/7-best-wordpress-backup-plugins-compared-pros-and-cons/

Merci de partager ! Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInPin on PinterestShare on StumbleUponEmail this to someone
Catégories