Sauvegarde différentielle site OVH via FTP avec LFTP (v5)
Grosse optimisation du script de sauvegarde v4. Voila la version v5.
La principale différence provient du fait que la sauvegarde n'est plus "full" (intégrale en bon français ), seuls les fichiers modifiés depuis la dernière sauvegarde sont rapatriés. Ce qui permet d'économiser grandement la volumétrie des données récupérées, seule la partie "utile" est transmise. Autant quand on a la fibre on s'en moque mais pour ceux qui ont de l'ADSL... De plus le temps de la sauvegarde en est grandement diminué. La cerise sur le gâteau étant de pouvoir faire une sauvegarde complète si besoin sans avoir à trafiquer quoi que ce soit.
Pour faire ce genre de sauvegarde différentielle, généralement on utilise un utilitaire qui s’appelle rsync, bien connu dans le monde Unix/Linux. Le problème de rsync étant qu'il ne fonctionne pas avec le protocole FTP. Pour un serveur mutualisé hébergé chez OVH cela ne fonctionnerait pas. J'ai pu trouver un utilitaire qui est capable de le faire qui est lftp dont voici la syntaxe :
Comme pour des commandes ftp classiques :
Pour pouvoir faire une copie différentielle il faut que lftp puisse comparer avec une "copie locale" du site évidemment. Donc il faut constamment conserver une image du site dans un dossier. Même si cela prend de la place, cela m'arrange bien. Les anciens scripts utilisaient un répertoire nommé simplement "work" qui était temporaire, supprimé en fin de script après le gzip). Sauf que dès que je devais restaurer un fichier, il fallait l'extraire du fichier conteneur .gz, qui est légèrement gros/lourd. Surtout quand on doit travailler avec du CPL (entre mon PC du salon et mon PC-NAS). Un dossier "mirror" existe et je peux y piocher dedans facilement via le partage Windows (Samba) sans avoir à passer par la case "extraction".
De plus j'ai décidé d'externaliser du script bon nombre de variables OVH. Elles sont maintenant placées dans un script (env.sh) qui les positionne toutes dans l'environnement sur un simple appel. Car j'ai d'autres scripts qui font d'autres choses sur le site. Tous mes identifiants/mots de passe sont donc centralisés au même endroit et ne sont pas éparpillés dans tous les scripts.
Pour l'occasion le script a été renommé, ce n'est plus backup_ovh.sh (v4) mais backup_site.sh (v5).
Remarques : On appelle .env.sh dans un premier temps puis ensuite backup_site.sh. Le script possède toujours son propre log. On autorise une remontée à 9 jours.
Ils sont disponibles dans ce dossier.
Note : Comme d'habitude les variables sont à remplacer dans les deux scripts.
Sauvegarde différentielle
La principale différence provient du fait que la sauvegarde n'est plus "full" (intégrale en bon français ), seuls les fichiers modifiés depuis la dernière sauvegarde sont rapatriés. Ce qui permet d'économiser grandement la volumétrie des données récupérées, seule la partie "utile" est transmise. Autant quand on a la fibre on s'en moque mais pour ceux qui ont de l'ADSL... De plus le temps de la sauvegarde en est grandement diminué. La cerise sur le gâteau étant de pouvoir faire une sauvegarde complète si besoin sans avoir à trafiquer quoi que ce soit.
Pour faire ce genre de sauvegarde différentielle, généralement on utilise un utilitaire qui s’appelle rsync, bien connu dans le monde Unix/Linux. Le problème de rsync étant qu'il ne fonctionne pas avec le protocole FTP. Pour un serveur mutualisé hébergé chez OVH cela ne fonctionnerait pas. J'ai pu trouver un utilitaire qui est capable de le faire qui est lftp dont voici la syntaxe :
Code BASH :
lftp -f " open ${OVH_FTP_SERVER} user ${OVH_FTP_LOGIN} ${OVH_FTP_PASSWD} lcd ${FINAL_DL_DIR} mirror --delete --verbose ${DIR_WWW} ${FINAL_DL_DIR} bye "
Comme pour des commandes ftp classiques :
- open : on ouvre la connexion vers {telle IP}
- user : on s'authentifie avec le couple user / password
- lcd : on change de répertoire courant localement (lcd = local cd = local change directory)
- mirror : commande magique de lftp de synchronisation
- bye : on quitte
Toujours conserver une copie en miroir - Restauration plus rapide
Pour pouvoir faire une copie différentielle il faut que lftp puisse comparer avec une "copie locale" du site évidemment. Donc il faut constamment conserver une image du site dans un dossier. Même si cela prend de la place, cela m'arrange bien. Les anciens scripts utilisaient un répertoire nommé simplement "work" qui était temporaire, supprimé en fin de script après le gzip). Sauf que dès que je devais restaurer un fichier, il fallait l'extraire du fichier conteneur .gz, qui est légèrement gros/lourd. Surtout quand on doit travailler avec du CPL (entre mon PC du salon et mon PC-NAS). Un dossier "mirror" existe et je peux y piocher dedans facilement via le partage Windows (Samba) sans avoir à passer par la case "extraction".
- Dans les autres dossiers il y a une copie gzippée (files.tar.gz) du site comme en v4.
- Pour ne pas interférer et pour être plus parlant, le nouveau nom du répertoire est "mirror" et il n'est pas effacé (comparé à "work").
Séparation
De plus j'ai décidé d'externaliser du script bon nombre de variables OVH. Elles sont maintenant placées dans un script (env.sh) qui les positionne toutes dans l'environnement sur un simple appel. Car j'ai d'autres scripts qui font d'autres choses sur le site. Tous mes identifiants/mots de passe sont donc centralisés au même endroit et ne sont pas éparpillés dans tous les scripts.
Renommage
Pour l'occasion le script a été renommé, ce n'est plus backup_ovh.sh (v4) mais backup_site.sh (v5).
Lignes en crontab
Code BASH :
jonathan@cerise:~$ crontab -l # Rappel syntaxe : m h dom mon dow command # Script de sauvegarde du site 30 23 * * * cd /docs/taverne/scripts/; . ./env.sh; ./backup_site.sh > /dev/null 2>&1 # Commande de purge des sauvegardes du site de plus de 8 jours. 00 03 * * * find /docs/taverne/sauvegardes/ -type d -ctime +8 -exec rm -r {} \; > /dev/null 2>&1
Remarques : On appelle .env.sh dans un premier temps puis ensuite backup_site.sh. Le script possède toujours son propre log. On autorise une remontée à 9 jours.
Code TEXT :
-------------------------------------------------------------- Sauvegarde différentielle débutée le 30-06-2017 @ 22:34:01. -------------------------------------------------------------- UUID généré : 9cc64e60-8d95-47e1-b3fa-10742b5d5751 Le dossier /docs/taverne/sauvegardes/ existe. RAS. Le dossier pour cette sauvegarde sera : /docs/taverne/sauvegardes/2017-06-30_22h34m01s/ Création du répertoire '/docs/taverne/sauvegardes/2017-06-30_22h34m01s/'... mkdir: création du répertoire '/docs/taverne/sauvegardes/2017-06-30_22h34m01s/' Répertoire créé OK. RAS. Le dossier de téléchargement sera : /docs/taverne/sauvegardes/mirror Création du sous-répertoire de travail ''... PHASE 1/5 : Appel de l'URL de génération du dump de la base MySQL... --2017-06-30 22:34:01-- XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Résolution de jonathandupre.fr (jonathandupre.fr)… 104.28.28.50, 104.28.29.50, 2400:cb00:2048:1::681c:1d32, ... Connexion à jonathandupre.fr (jonathandupre.fr)|104.28.28.50|:80… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : non indiqué [text/html] Enregistre : «/docs/taverne/sauvegardes/2017-06-30_22h34m01s/temp.log» 0K 11,4M=0s 2017-06-30 22:34:09 (11,4 MB/s) - «/docs/taverne/sauvegardes/2017-06-30_22h34m01s/temp.log» enregistré [183] Appel génération du dump SQL OK. Votre base est en cours de sauvegarde dans le fichier 9cc64e60-8d95-47e1-b3fa-10742b5d5751... Compression du fichier... C'est fini. Vous pouvez récupérer la base gzippée par FTP ! PHASE 1/5 : Fin d'appel de l'URL de génération du dump de la base MySQL. Temporisation de 2 secondes... PHASE 2/5 : Récupération de la base de données gzippée... -rw-rw-r-- 1 jonathan jonathan 1098316 juin 30 22:34 /docs/taverne/sauvegardes/2017-06-30_22h34m01s/sql_export.sql.gz Dézipppage du dump... -rw-rw-r-- 1 jonathan jonathan 4418638 juin 30 22:34 /docs/taverne/sauvegardes/2017-06-30_22h34m01s/sql_export.sql PHASE 2/5 : Fin de la récupération du dump de base de données. Temporisation de 2 secondes... PHASE 3/5 : Suppression du dump MySQL sur le serveur... Connected to ftp.cluster007.ovh.net. 220- ~~~ Welcome to OVH ~~~ 220 This is a private system - No anonymous login 331 User XXXXXXXXXXXXXXXXX OK. Password required 230 OK. Current restricted directory is / Remote system type is UNIX. Using binary mode to transfer files. 250 OK. Current directory is XXXXXXXXXXXXXXXXXXXXXXXXXXXX 250 Deleted XXXXXXXXXXXXXXXXX/9cc64e60-8d95-47e1-b3fa-10742b5d5751.sql.gz 221-Goodbye. You uploaded 0 and downloaded 0 kbytes. 221 Logout. PHASE 3/5 : Fin de la suppression du dump MySQL sur le serveur. Temporisation de 2 secondes... PHASE 4/5 : Récupération du site internet... source: est un dossier Suppression de l'ancien fichier « www/cache/CacheManager-articles-categories.data » Transfert du fichier « www/cache/CacheManager-articles-categories.data » Suppression de l'ancien fichier « www/cache/CacheManager-kernel-last-use-date.data » Transfert du fichier « www/cache/CacheManager-kernel-last-use-date.data » Transfert du fichier « www/files/mainboards/manuals/intel_se440bx-2.pdf » Suppression de l'ancien fichier « www/piwigo/_data/cache/0eec5ef0566605ee24fe3ffcb7f8d42f.cache » 8,9G /docs/taverne/sauvegardes/mirror PHASE 4/5 : Fin de la récupération du site internet. Temporisation de 2 secondes... PHASE 5/5 : Compression des fichiers... -rw-rw-r-- 1 jonathan jonathan 8552582005 juin 30 23:01 /docs/taverne/sauvegardes/2017-06-30_22h34m01s/files.tar.gz PHASE 5/5 : Fin de la compression. Temporisation de 2 secondes... -------------------------------------------------------------- Fin des opérations ! Sauvegarde différentielle terminée le 30-06-2017 @ 23:01:23. --------------------------------------------------------------
Les scripts
Ils sont disponibles dans ce dossier.
Note : Comme d'habitude les variables sont à remplacer dans les deux scripts.