Déploiement et sauvegarde

J’ai terminé la migration de mon serveur. Comme annoncé j’ai utilisé l’outil de déploiement Ansible pour :

  • conserver l’historique d’installation du serveur,
  • valider au préalable sur une machine virtuelle locale l’installation de nouveaux services,
  • être capable de rapidement redéployer un nouveau serveur.

J’ai d’abord écrit un playbook de base qui configure à mon goût une Debian fraîchement installée : paquets supplémentaires, création des utilisateurs, préférences de Bash, Tmux et Vim. Les préférences sont récupérées depuis mon projet dotfiles sur GitHub et Ansible s’occupe de leur installation. Si demain je modifie mon prompt Bash ou si rajoute un plug-in à ma configuration Vim, je peux facilement synchroniser les changements avec un git pull. Ce playbook m’a déjà resservi sur le plan professionnel, c’est un investissement de temps déjà rentabilisé. Je l’ai publié dans un projet provisioning sur GitHub.

Le second playbook est beaucoup plus personnel puisqu’il déploie ce blog. En cas de pépin il me permettra de me remettre en ligne rapidement. C’est un playbook qui peut servir de tutorial, il n’est pas complexe mais mixe différents types de tâches : installation de fichiers, manipulation de GIT, enregistrement de tâches dans Cron.

Ceci dit, à contrario de mon idée initiale, je n’ai pas écrit de playbooks pour l’intégralité des services à déployer car c’est très consommateur en temps (or je suis fainéant : souvenez vous je suis développeur) et c’est peu intéressant pour des services faciles à installer et périssables. Je prends pour exemple Piwik, l’outil de statistiques de site Web ; c’est une application LAMP (Linux, Apache, MySQL, PHP) classique qui par la suite est capable de se mettre à jour elle-même. Je n’ai pas vu d’intérêt à créer un playbook pour installer une version de Piwik qui sera obsolète dans 2 mois et de passer du temps à maintenir un playbook au lieu de maintenir mon serveur. Mes autres services, soit moins critiques, soit mis à jour automatiquement ont donc été installés manuellement : Piwik, Tiny Tiny RSS, Owncloud, Shaarli et Roundcube.

L’installation est donc achevée, je suis à priori capable de remonter le blog en moins de deux heures sur un nouveau serveur (ce qui prendra plus de temps c’est de faire pointer les DNS vers la nouvelle adresse du site). Il me reste à détailler le sujet des sauvegardes.

Mon besoin est modeste mais précis :

  • les articles du blog sont déjà sauvegardés dans GitHub (merci les blogs statiques) mais je dois sauvegarder les commentaires,
  • sauvegarder la base de donnée MySQL de Tiny Tiny RSS n’a aucun intérêt mais sauvegarder le fichier OPML qui contient mes abonnement RSS est important,
  • sauvegarder mes favoris conservés par Shaarli est essentiel,
  • peu m’importe mes fichiers synchronisés avec Owncloud puisque j’ai une copie locale par contre il m’importe de sauvegarder mon calendrier.
  • sauvegarder les configuration du serveur HTTP (NginX dans mon cas)

Ma solution est atypique et peut-être un mauvais exemple mais elle répond à mon besoin et je n’avais aucune envie de sortir la grosse artillerie, de dumper toutes mes bases et tout mon répertoire /var/www avec des centaines de fichiers pour créer des grosses archives sauvegardées incrémentalement vers … un FTP distant ou autre. Je suis parti du principe qu’en cas de crash, je serais capable de remonter le blog rapidement et que je prendrais plus de temps pour remonter mes services donc je focalise sur les données de ces services. Ce qui est important par contre, c’est d’avoir une sauvegarde avec rotation qui conserve les 2 derniers jours, 2 dernières semaines et 2 derniers mois pour avoir un historique et revenir en arrière en cas de problème. J’ai donc personnalisé un modeste shell script qui a le bon goût de gérer la rotation des sauvegardes, pour :

  • d’abord récupérer toutes mes données à sauvegarder à droite à gauche par différents moyens : copie, extraction avec les API proposées par les applications,
  • et ensuite envoyer la sauvegarde quelque part.

Sachant que je n’ai pas d’autre serveur ou d’espace FTP je me suis demandé où serait ce quelque part. J’ai regardé un peu la solution Hubic mais la complexité pour en détourner l’usage de base qui est la synchronisation de fichiers et monter l’espace Hubic comme stockage distant m’a peu motivé. Une sauvegarde c’est bien quand ça fait son boulôt et qu’on l’oublie. J’ai moins de 2 Mo à sauvegarder par jour j’ai donc eu une idée, tordue au premier abord et peut-être bien aussi au second (d’un autre côté je suis le gars qui s’acharne à greffer des systèmes de commentaires à des blogs statiques donc ça n’étonnera peut-être pas grand monde) : balancer mes sauvegardes dans Owncloud ainsi elles seront synchronisées sur mes machines locales et j’aurais une notification journalière que la sauvegarde s’est bien déroulée.

Voici donc les grandes lignes de la partie récupération des données :

    # Les fichiers de configuration de NginX
    cp -r /etc/nginx/* $TARGET_DIR/nginx/.

    # Les favoris de Shaarli stockées dans des fichiers PHP
    cp /var/www/shaarli/data/* $TARGET_DIR/shaarli/.

    # Le fichier OPML de Tiny Tiny RSS par son URL publique
    wget "http://ttreader.madyanne.fr/opml.php?op=publish&key=XYXYXYXYXYXYXYXYXYX" \
           -O $TARGET_DIR/reader/reader.opml

    # Le fichier ICS du calendrier Owncloud
    OC_USER=owncloud_user
    OC_PWD=owcloud_password
    wget --no-check-certificate --auth-no-challenge --no-clobber \
         --http-user=$OC_USER --http-password=$OC_PWD \
         -O $TARGET_DIR/owncloud/cal.ics \
         "https://owncloud.madyanne.fr/index.php/apps/calendar/export.php?calid=1"

Suite à cela, le script crée une belle archive et la copie dans un répertoire backup de mes fichiers Owncloud. Ce n’est pas suffisant pour qu’elle soit synchronisée par Owncloud car on l’a copié en douce. Il faut forcer Owncloud à rescanner son répertoire avec la commande suivante exécutée en tant qu’utilisateur www-data:

    su -c "/usr/bin/php /var/www/owncloud/console.php files:scan all" \
        -s /bin/sh www-data

Il reste encore un peu de peaufinage mais ça semble faire le boulôt et je vois la fin du tunnel de cette migration de serveur.

C138 - 2015-06-22 10:07:02

“peu m’importe mes fichiers synchronisés avec Owncloud puisque j’ai une copie locale”

Même conclusion… erronée ;)

Attention, une bourde dans les fichiers stockés sera synchronisée, propagée partout vitesse V. Il faudrait au moin sauvegarder (évidemment) la zone data du serveur owncloud.

(sauf à avoir activé le versionning owncloud…et encore)

Sinon, merci pour les infos/astuces complémentaires ;)

Purexo - 2015-07-23 13:13:56

Pour ma part, je gère 3 serveurs avec 2 à 3 comptes utilisateurs sur chaque (un dédié pour antarka.com, un vps pour starbound-fr.net, et un autre vps pour purexo.eu)

J’ai testé plusieurs système de sauvegarde journalière, j’ai commencé par du classique puis je me suis dit que ça pourrais être pas mal de faire de l’incrémentielle. Je me suis donc arrêté sur de l’incrémentielle et j’attends de voir ce que ça donne sur le long terme.

Concernant la sauvegarde sur espace distant la seule solution viable que j’ai trouvé c’est Mega.co.nz (que du coup je conseille à tout ceux qui ont besoin de faire de la sauvegarde en cli). Avec 50Go de place gratuite par compte il y a de quoi faire (au pire on créé de nouveaux comptes :3)

Pour les bases de données j’en suis au stade expérimentale en sauvegardant les .sql dans un dossier git (j’ai une bdd qui pese plus de 600Mo, je compte donc sur git pour me la versionner pour pas avoir 600Mo “inutile” à sauvegarder chaque jours). D’ailleurs je pourrais peut être sauvegarder uniquement le git bare (.git) plutot que le dossier git complet.

Au niveau du processus J’ai un dossier Sauvegardes dans /root avec différents sous dossiers. Par exemple nginx, user, siteweb

Dans chacun de ces dossiers j’exécute un archivage incrémentielle du dossier lié. Par exemple pour nginx :

jour=`date "+%Y%m%d%H%M"`    
tar -Jcf /root/Sauvegardes/nginx/$jour.tar.xz --listed-incremental=/root/Sauvegardes/nginx/save.list /etc/nginx

Ensuite je supprime du dossier mega les save.list (sinon il seront pas à jours) Ensuite j’envois le tout sur Mega via le tool megacopy (de megatools) (concernant megatools je conseille de le compiler plutôt que de passer par les dépôts, protips pour compiler megatools :

.# c'est pas écris dans la doc, mais si c'est pas présent megatools ne fonctionnera pas        
apt-get glib-networking     
./configure --disable-shared --enable-static    

ça évite pas mal de soucis)

megacopy -l /root/Sauvegardes -r /Root/Sav

Et ensuite je m’envois un mail avec le recap de ce qui c’est passé (à chaque commandes du script je redirige la sortie d’erreur (et parfois celle d’info) vers un fichier de recap)

En tout cas je suis content d’avoir découverts ton blog ^^

mike95 - 2015-07-31 13:56:31

cool!

Thomas - 2018-11-27 11:48:52

Bonjour,

Comment écraser les dossiers et fichiers distants avec megacopy ?

Votre commentaire
Le site Web est optionel
Le message peut être rédigé au format Markdown