Afin de prévenir une panne, un crash de son serveur ou quoi que ce soit d’autre, il est primordial de penser à faire des sauvegardes. Voici comment je procède pour sauvegarder mes sites (WordPress ou autres) et leur(s) bases de données.
Aujourd’hui j’ai définitivement, temporairement, décidé d’arrêter de me prendre la tête avec Docker. J’ai donc migré ce WordPress vers une VM Debian « standard » avec Nginx, PHP7.1-FPM et MariaDB. L’occasion de revoir mon système de sauvegarde, et d’écrire ce mémo. A chaque fois que je dois toucher RSYNC (~ 1 fois par an) je me prends la tête pour le remettre en place… Alors je vais essayer d’être le plus clair possible.
Au fait pourquoi je parle de RSYNC ? Car faire des sauvegardes de son WordPress (fichiers + BDD) c’est bien, les stocker ailleurs que sur le même serveur c’est mieux c’est INDISPENSABLE !
<parano>Les envoyer sur deux autres emplacements différents et distincts géographiquement parlant c’est encore +++ mieux</parano>
Sauvegarde de la base de données WordPress
Deux choses à distinguer pour sauvegarder un WordPress : la base de données et les fichiers du dossier wp-content
.
On commence donc par la base de données. Comme on veut éventuellement récupérer une info sur l’état de la sauvegarde on va scripter ça en bash et s’envoyer un mail pour nous avertir en cas de pépins. 😉 On va également mettre en place une rétention/rotation des sauvegardes sur quelques jours au cas où. Cela fait maintenant un an que je procède de la sorte (à peu près) pour les sauvegardes de Météo06, et ça marche bien.
La première chose est de mettre en place les répertoires de travail :
Le /home/backup/*
sera l’emplacement des sauvegardes, le /home/backup_temp/
sera l’emplacement temporaire des sauvegardes et le /home/scripts/backup/
sera l’emplacement des scripts de sauvegardes.
Création d’un utilisateur pour le dump
Afin de sécuriser un peu le process de sauvegarde, il est préférable de créer un utilisateur MySQL spécifique pour le dump. Cela peut se faire de manière graphique avec PHPMyAdmin ou Adminer. Sinon tapez « mysql » pour se connecter en root, puis :
Création du script
On va créer le premier script pour la/les BDD :
Et on y insère :
Les mails
Maintenant pour que le serveur puisse envoyer des mails, vérifier le hostname de votre serveur (le mieux est qu’il corresponde à votre domaine), puis :
Ensuite il faut dire à Exim qu’il a le droit d’envoyer des mails en dehors du localhost, pour cela suivre ce tuto et :
Test du script
Enfin pour lancer le script afin de tester son bon fonctionnement :
Sauvegarde du répertoire WordPress
On va maintenant pouvoir refaire à peu près la même chose avec le répertoire web de WordPress. Pour ma part je ne sauvegarderai que le répertoire wp-content
afin d’économiser de la place et du temps, étant donné que tout ce qui est en dehors de ce répertoire est censé rester générique et propre à l’installation même de WordPress (mis à part le fichier wp-config.php
, mais on va l’intégrer à notre sauvegarde). On en profitera aussi pour ajouter le répertoire de scripts à notre sauvegarde.
Création du fichier backup_www.sh
, et on y insère :
Test du script
Pas grand-chose de plus à faire puisque les mails ont déjà été configurés avant, donc plus qu’à le tester :
Vérification des sauvegardes effectuées
Pour finir sur la création des sauvegardes, on n’oublie pas de les contrôler en les décompressant :
Automatisation des scripts de sauvegardes
Pour que ces sauvegardes se fassent toutes seules la nuit (ou n’importe quand), on va simplement enregistrer une cache cron en faisant crontab -e
:
À 1 heure du matin, on exécute la sauvegarde de la base de données, puis à 1h30 on exécute la sauvegarde des fichiers.
RSYNC pour exporter les sauvegardes
Je le disais au départ, le plus important réside dans la disponibilité des sauvegardes. Si elles restent stockées sur le même serveur, elles ont peu de chance d’être utiles le jour ou on en aura le plus besoin ! C’est à dire le jour ou le disque dur de votre serveur pète par exemple…
Bref, pour répondre à ce besoin d’export des sauvegardes préalablement créées, j’utilise RSYNC pour copier chaque nuit les nouvelles sur un autre serveur. On a vu qu’on avait une rotation de 7 jours sur les backups de la BDD (+ un backup chaque début de mois conservé dans un dossier à part). Même chose pour les sauvegardes du répertoire web puisque les fichiers sont nommés avec le jour de la semaine (lundi, mardi, etc.) et s’écrasent petit à petit (+ un backup en milieu et début de mois).
On va donc configurer RSYNC pour qu’il compare le répertoire de stockage des sauvegardes avec le répertoire distant pour ensuite ne copier que ce qu’il y a de nouveau.
Pour ma part j’envoie mes sauvegardes sur un Kimsufi (KS-2), et sur mon NAS qui est chez moi. Peu de chances de tout perdre d’un coup. 😉
Serveur source
Sur le serveur ou se trouve WordPress on va installer RSYNC (apt install rsync
) puis activer son démon :
Il faut maintenant créer un utilisateur rsync
, puis créer une clé SSH que l’on copiera ensuite sur le serveur de backup (ici le KS avec un utilisateur exprès pour RSYNC également) :
Voilà, nous avons maintenant une connexion SSH entre nos deux serveurs possible sans mot de passe.
On va donc pouvoir créer notre script :
Jusque-là tout est bon, mais comme nous allons faire tourner ce script avec l’utilisateur rsync
il reste un petit détail à faire. Comme ce n’est pas cet utilisateur qui créer les sauvegardes dans le dossier /home/backup
, il n’aura pas les droits suffisants pour les envoyer sur le serveur de backup. On va donc ajouter une ligne à la fin de backup_bdd.sh
et backup_www.sh
pour changer les droits de ce dossier à chaque fin de sauvegarde :
On va pouvoir le tester sans se connecter à notre utilisateur rsync
, mais d’abord on attribue on créer le répertoire des logs et on attribue les bons droits :
Automatisation du script RSYNC
Si tout fonctionne manuellement on va pouvoir enregistrer une tache cron, mais cette fois-ci, il faut que ce soit l’utilisateur rsync
qui effectue cette tâche.
Il faut donc créer un fichier nommé par exemple rsync_wordpress
dans le répertoire /etc/cron.d/
:
Voili voilou, normalement avec ça on doit pouvoir dormir plus paisiblement en attendant le crash de son serveur. 😉
Si vous utilisez RSYNC autrement, ou si vous avez des conseils à me donner, n’hésitez pas ! Il y a des tonnes de manières de faire pour les sauvegardes. Mais le plus important est probablement de ne pas oublier de vérifier de temps en temps que votre script fonctionne. Avec un mail dans votre boite pour vous indiquer le succès (ou l’échec) de l’opération, ça réduit déjà les risques d’oublier. Je détaillerais dans un autre article comment je procède pour envoyer ensuite ces sauvegardes sur mon NAS QNAP. Histoire de vraiment dormir tranquille ! 😉