GuiGui's show

Table des matières

Dans ce billet, je vais vous parler de la sauvegarde de vos applications web (site classique, CMS, ...). Évidemment, je ne vais pas parler de tous les cas et vous devriez donc adapter ce billet à votre situation. Ce billet a plus vocation à expliquer la méthodologie à mettre en place plutôt que l'exhaustivité des situations. Je ne parlerai pas des motivations qui peuvent vous amener à réaliser des sauvegardes ou des principes de base d'une bonne sauvegarde (régulière, garantissant l'intégrité des données, ...) car c'est du vu et revu.

Sauvegarde des fichiers

La première chose à faire est de sauvegarder les fichiers de votre application. Le protocole est au choix : FTP, FTPs, SCP, ... Il convient de se demander ce qu'il faut sauvegarder. En effet, si dans le cas d'une application @home (= personnelle), il convient de garder l'intégralité de l'arborescence, ce n'est pas nécessaire avec un CMS utilisant une base de données, par exemple. Exemple : pour WordPress, seul le dossier wp-content/uploads est important. Le reste (plugins, thème, reste des fichiers) peut facilement être récupéré et réinstallé.

Si jamais votre application web stocke ses données dans des fichiers, je vous conseille, dans un souci de cohérence des données sauvegardées, de bloquer l'accès à l'application durant la sauvegarde. Un fichier .htaccess placé à la racine de votre application web avec ce contenu devrait suffire :

Deny from all

Note : Non, je ne pense pas que bloquer l'accès à votre site personnel durant 2 minutes vous soit dommageable, surtout si vous le faites dans le créneau horaire où vous avez le moins de visiteurs. Après, pour les grosses applications/applications professionnelles, on peut discuter de ce principe.

Sauvegarde de la base de données

Si votre application utilise une base de données, il convient évidemment d'en exporter les données. Là encore, les méthodes sont nombreuses selon l’accès que vous avez au serveur : commande (mysqldump, pg_dump, ...) ou application web (phpmyadmin, phpPgAdmin, ...), etc..

Là encore, je vous conseille de bloquer l'accès à l'application durant la sauvegarde.

Voici les paramètres que j'utilise avec phpmyadmin (cela peut-être adapté à la commande mysqldump sans aucune difficulté) :
On vérifie que toutes les tables sont sélectionnées. On vérifie que le mode de sauvegarde est bien SQL. On vérifie que les rubriques "Structure" et "Données" sont bien cochées afin d'exporter l'intégralité des données.

Enclose export in a transaction // Utiliser le mode transactionnel : utilise le principe des transactions : si la sauvegarde se termine alors elle sera complète, sinon elle ne vous sera pas proposée. C'est un mode "tout ou rien". Je pense que c'est une sécurité et qu'il vaut mieux l'activer.

Disable foreign key checks // Désactiver la vérification des clés étrangères : évidemment, on laisse cette option désactivée ... dois-je vraiment expliquer pourquoi ?

Add DROP TABLE / DROP VIEW // Ajouter DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT : permet, lors de la restauration, de supprimer la table et la récréer si elle existe encore dans la base. Cette option est une bonne idée et devrait être cochée. Cela garantit que des anciennes données (sauvegarde) ne seront pas mélangées avec les nouvelles données. On obtient donc une garantie de cohérence des données. Si la sauvegarde commence à dater, il est par contre évident que l'on perd beaucoup de données. Mais une sauvegarde doit être régulière donc ce problème ne se pose pas ;).

Add IF NOT EXISTS // Ajouter IF NOT EXISTS : Si elle n'est pas présente et qu'une table porte le même nom lors de la restauration, vous aurez une erreur "Table already exists" et rien ne sera fait. Si elle est présente et qu'une table porte le même nom, vous n'aurez pas l’erreur précédente car le script n'essayera pas de recréer la table mais vous aurez une erreur en rapport avec les index lors de l'insertion des données dans la table ("Duplicate entry 'Dodo-1' for key 'PRIMARY' "). Et là, rien ne vous dit que des données n'ont pas été insérées avant que le SGBD ne rencontre une clé identique et vous en informe. Bref, cette option n'est pas une bonne idée.

Complete inserts ou Extended inserts // Insertions complètes ou Insertions étendues : il convient d'activer les deux. Voir pourquoi ici.

Use delayed inserts // Insertions avec délais : cette option n'est pas une bonne idée. Elle permet de mettre en queue les insert si la table est déjà utilisée. Une bonne restauration doit se faire offline pour éviter toute perte de données/incohérence donc nous n'avons pas besoin de cette option.

Use ignore inserts // Ignorer les erreurs de doublons : cette option n'est pas non plus une bonne idée : si des doublons existent au niveau des indexes, il vaut mieux en être informé que d'ignorer leur présence (même s’il valait mieux découvrir leur présence avant de faire une restauration post-crash, je suis d'accord :P).

Export type // Type d'exportation : insert. Update suppose que les données soient présentes, ce qui n'est pas le cas après un crash et replace peut insérer des incohérences entre plusieurs tables dans le cas où on restaure qu'une seule table, par exemple. Le mieux reste donc l'option DROP + Insert.

Le reste des options n'a pas d'importance : on peut choisir d'exporter les triggers, les vues, etc., et on laissera le reste des options sur leurs valeurs par défaut : nous avons réglé l'essentiel.

On vérifie que la case "Save as file" // "Transmettre" est cochée. On choisit également un mode de compression.

On lance la sauvegarde.

Sauvegarde du contenu "en clair"

Il me paraît important de sauvegarder les données de l'application web au format texte brut (ou autre format humainement lisible, libre et ouvert pour les données non représentables textuellement) quand cela est possible. Cela permet d'une part, d'être plus indépendant de l'application web utilisée qu'un script de conversion qu'il faudra créé lorsque l'on voudra changer de CMS, par exemple. D'autre part, cela permet d'avoir une sauvegarde humainement compréhensible dans le cas où la sauvegarde principale ne fonctionne plus (je pense notamment à un dump SQL refusant d'être restauré).

Cette sauvegarde devrait être réalisée à la main plutôt que par un logiciel/extension. Je vous rappelle, en effet, qu'un logiciel est forcement buggé (ou insuffisamment testé).

En cas de crash complet, il faudra réinjecter les données à la main dans l'application quand c'est possible et nécessaire (cas des billets d'un blog) ou bien garder ces sauvegardes en souvenir (cas des stats d'un site).

Évidemment, tout cela n'est pas toujours possible selon le volume de données, leur nature, ...

Je vais néanmoins vous donner deux exemples :

WordPress

Le plus important ici, c'est bien évidemment les billets que vous avez publié, voire les commentaires de vos visiteurs.

Pour conserver vos billets, il suffit de créer un bête fichier texte ayant une structure comme celle-ci, par exemple :
Titre :
Auteur (si plusieurs posteurs) :
Date de publication :
Catégories :
Mots-clés :
Contenu :

Il suffit ensuite de remplir ce modèle avec les données issues de l'administration de WordPress et plus précisément de la page vous permettant de modifier les billets. Pensez à sauvegarder les balises HTML, tout quoi.

Pour conserver les commentaires de vos visiteurs, il suffit de créer un bête fichier texte ayant une structure comme celle-ci, par exemple :
Auteur :
Email :
Site Web :
Date :
Contenu :

Il suffit ensuite de remplir ce modèle avec les données issues de l'administration de WordPress et plus précisément de la page vous permettant de modérer les commentaires.

Si les commentaires vous tiennent à cœur et que vous avez un blog à fort trafic, vous pouvez toujours envisager l'écriture d'un script ...

Piwik

Ici, le plus important, c'est les statistiques. Un plugin, PDFReports, permet la création de rapports au format PDF ou HTML. Il peut même vous l'envoyer par mail à une fréquence déterminée.

Si vous n'avez pas sauvegardé vos statistiques et que vous avez installé Piwik il y a peu de temps

Vous pouvez envisager d'utiliser PDFReports. Cliquez sur le lien "Rapports e-mail" dans le header de l’interface web de Piwik. Dans le calendrier, choisissez la période à exporter. Cliquez ensuite sur le lien "Créer et planifier un rapport". Saisissez une description de la sauvegarde. Choisissez "Jamais" dans la liste déroulante "Planification courriel" et décochez "Envoyer à moi". Choisissez HTML comme format du rapport. Choisissez les données que vous souhaitez exporter. Enfin, cliquez sur le bouton "Mettre à jour le rapport". Cliquez sur "Télécharger" pour récupérer le rapport.

Maintenant, pour chaque période que vous souhaitez sauvegarder, cliquez sur le calendrier, choisissez la période et cliquez sur "Télécharger".

Note : Si, quand vous cliquez sur le bouton "Mettre à jour", une ligne "Chargement des données" apparaît mais ne disparait pas ou si votre rapport n'apparait pas dans la liste, pendez à actualiser la page (F5) : ceci est probablement dû à un problème avec le cache.

Néanmoins, les rapports ont une quantité limitée de données (ex. : les 30 derniers mots-clés). Si vous souhaitez outrepasser cela (il faut néanmoins se poser la question de la pertinence de la sauvegarde de ces données supplémentaires vis-à-vis du poids qu'elles vont occuper), regarder ci-dessous.

Si vous n'avez pas sauvegardé vos statistiques et que vous avez installé Piwik il y a longtemps

Il faut utiliser l'API de Piwik pour générer, de manière automatique, un rapport pour une période donnée. Vous pouvez également débloquer la limite de lignes dans chaque rubrique du rapport comme expliqué ci-dessus. Enfin, dans le cas où la création du rapport est impossible depuis l'interface web (je n'ai pas compris pourquoi cela bug chez certains hébergeurs), l'API permet de créer un rapport.

Ces cas d'utilisation sont évoqués, pour plus de clarté, dans un autre billet : Utiliser l’API de Piwik pour générer des rapports

Essayer ses sauvegardes

N'oubliez pas de toujours essayer vos sauvegardes. Si vous avez sauvegardé votre base de données, essayez de la restaurer dans une autre base, si vous avez sauvegardé vos fichiers, essayez-les sur un autre serveur. Ce n'est pas compliqué de se monter un serveur de test local (pour ceux qui n'en ont pas encore et qui effectuent leurs modifications directement sur le serveur de production) : il y a le moyen artisanal (tout installer et configurer à la mano) ou utiliser des logiciels qui font tout à votre place (ex. : WampServer).

Enfin n'oubliez pas :

• Faites un plan de sauvegarde de vos applications web qui leur correspondent. Il est vain d'appliquer bêtement un modèle donné sans réfléchir aux données que l'on doit sauvegarder.
• Les sauvegardes, c'est comme le sexe chez les adolescents 😉