Articles - Logiciel & scripts

Sauvegarde différentielle site OVH via FTP avec LFTP (v5)

  |   571  |  Commentaire (1)  |  Logiciel & scripts
Grosse optimisation du script de sauvegarde v4. Voila la version v5.

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 au final 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). Au final : 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 :
 
[email protected]:~$ 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.

D'autres sites d'exemple