Un site web a toujours besoin d’être sauvegardé, coûte que coûte et quel qu’il soit. Pour se faire, j’ai décidé de faire mon propre script de sauvegarde, pour un serveur web nginx ayant un site web et une base de données.

Je me suis aidé du script de MEMO-LINUX, à cette adresse. J’ai utilisé quelques lignes de code et ajouté les variables, histoire d’avoir un script encore plus malléable. Encore merci à Fred pour son script !

L’idée, c’est de sauvegarder tous les fichiers d’un site web, sa base de données et les fichiers de configuration du serveur web en un seul et même endroit. J’ai donc prévu de compresser le dossier source du site web, le dossier de configuration du serveur web et un export de la base de données.

Vous comprendrez qu’il y a deux serveurs : le premier serveur (la source même) et un second serveur qui me sert de backup. Comme il s’agit de fichiers compressés, je ferai un « SCP » pour transférer les fichiers de mon serveur source vers mon serveur de sauvegarde.

Sur le serveur source, deux commandes vont être à effectuer pour pouvoir vous connecter via SSH et via un échange de clés. La première commande permet de générer la première paire de clé, tandis que la seconde commande envoie la clé publique dans les clés autorisées de votre serveur de backup.

ssh-keygen ssh-copy-id -i ~/.ssh/id_rsa.pub root@serv_backup

Lors de l’exécution de la seconde commande, vous devrez accepter l’empreint (l’identification) et ensuite saisir le mot de passe du compte utilisateur « root ». Si tout s’est effectué correctement, vous devriez pouvoir faire un « ssh root@serv_backup » et vous connecter instantanément, sans mot de passe.

Sur le serveur de sauvegarde, j’ai décrété que les dossiers de sauvegarde seront les « /home/backup/db » (pour les fichiers de la base de données), « /home/backup/site » pour tous les fichiers concernant le site web et enfin « /home/backup/srv » pour tous les fichiers de configuration du serveur. N’oubliez donc pas de créer les dossiers nécessaire avant de lancer votre sauvegarde. Evidemment, vous pouvez modifier l’emplacement de ces dossiers sur votre serveur de sauvegarde, n’oubliez pas de modifier alors le script au niveau des premières variables.

Le script !

Le tant attendu… ! Pour éviter la pollution, j’ai mis le script directement sur Github – vous pouvez le forker si vous le souhaitez, la licence le permet 🙂 Je serai curieux de voir vos optimisations / ajouts / suppressions ! Retrouvez le à cette adresse : https://github.com/Mettmett/debian-backup-wp

Que fait-il ?

Dans un premier temps, toutes les variables sont définies – c’est ici que vous pouvez personnaliser le script.

Direction le dossier « /tmp », pour éviter de stocker les fichiers de sauvegarde n’importe où sur votre serveur source.

Export de la base de données via un « mysqldump » – suite à cet export, compression du fichier « .sql » en « .gz ».

Ce fichier est ensuite envoyé sur le serveur de sauvegarde

Compression des dossiers comportant le site web et envoi vers le serveur de sauvegarde

Compression des dossiers comportant les configurations du serveur web et envoi vers le serveur de sauvegarde

Inutile de garder les fichiers temporaires > suppression des fichiers précédemments envoyés sur le serveur de sauvegarde

That’s all folks !

Script assez simple en soi ! Et pourtant, tellement pratique et puissant… ! Il reste une dernière étape : l’automatisation. Pour cela, utilisation du crontab – n’ouvrez pas manuellement le fichier /etc/crontab, vos modifications ne seraient alors pas prise en compte.

crontab -e

Enfin, à l’intérieur, il faut saisir ce type de ligne :

0 */6 * * * /root/save_web.sh > /dev/null

En clair, toutes les 6 heures, le script à l’emplacement « /root/ » intitulé « save_web.sh » sera exécuté. Une nouvelle fois, vous pouvez modifier cette ligne selon vos besoins et vos envies. Tout dépend de votre serveur / infrastructure / criticité de vos données.

Quelques pistes d’optimisation

N’étant pas un expert du shell, je suis quand même confronté à quelques ennuis :

pas de gestion de logs, plutôt dommage pour avoir en retour en cas d’erreur

pas de gestion d’erreurs (par exemple, si pb lors de l’exécution, le script reste bloqué indéfiniment…)

pas de gestion de la rétention des sauvegardes (à la fin du script vous verrez une ébauche… mais ce n’est pas encore ça)

votre bout de code ? 🙂

A vous de jouer !