meta title="Sauvegardes..."

Sauvegardes...

Maintenant que je dispose d'un vrai blog et d'un vrai outil de gestion de photos en ligne, que le tout fonctionne correctement, il ne faut pas que j'oublie la partie sauvegarde... Ca serait bête de tout avoir à recommencer "from scratch..."

Sauvegarde du blog

L'objectif est de permettre de récupérer les informations importantes du blog, aussi bien les données (le corps des billets) que les documents téléchargés. Pour rappel, dans ma configuration, Serendipity utilise une base de données SQLite.

D'une manière générale, je poserai les fichiers de sauvegarde dans /opt/backup, répertoire qu'il faudra auparavant créer par l'utilisateur root en ayant soin de rendre le répertoire inaccessible à toute autre personne que l'utilisateur root: * mkdir /opt/backup * chmod 700 /opt/backup

Les photos étant des fichiers assez volumineux, j'utiliserai au maximum la compression bzip2 qui donne d'excellents résultats (bon c'est compensé par une super lenteur lors de la compression/décompression mais ici, c'est bien l'objectif de place qui est priorisé). Le paquet bzip2 est donc indispensable: aptitude install bzip2.

Sauvegarde de la base de données:

Les bases de données SQLite sont constituées d'un simple fichier où il y a tout dedans. Le concept est simple. Si la base de données n'est pas en fonctionnement, il suffit de copier le fichier pour faire une sauvegarde. Dans le cas de Serendipity, le fichier est /var/lib/dbconfig-common/sqlite3/serendipity/serendipity

En étant prévoyant, je préferre les exports SQL. Pour cela, il nous faut un outil de base: sqlite3 qui est une interface en ligne de commande pour attaquer une DB SQLite V3. L'installation est assez simple: aptitude install sqlite3.

Ensuite, l'export SQL peut se faire par la commande suivante:

echo '.dump' | sqlite3 /var/lib/dbconfig-common/sqlite3/serendipity/serendipity | bzip2 -c > /opt/backup/serendipity.sql.bz2

Sauvegarde des fichiers:

Mon but est de sauvegarder les fichiers uploadés sur le serveur ainsi que les fichiers de configuration. Les fichiers uploadés se trouvent dans /var/lib/serendipity/uploads et les fichiers de conf dans /etc/serendipity. Classiquement sous GNU/Linux (et sans doute sous Unix), on utilise la commande tar pour faire ça:

  • fichiers de configuration: cd / ; /bin/tar -cjf /opt/backup/serendipity_conf.tar.bz2 etc/serendipity
  • fichiers upload: cd / ; /bin/tar -cjf /opt/backup/serendipity_upload.tar.bz2 var/lib/serendipity/uploads

Sauvegarde des galeries d'images:

Je ne vais pas revenir sur les explications antérieures sur les sauvegardes, sauvegarder gallery signifie:

  • Sauvegarder les fichiers de configuration
  • Sauvegarder les fichiers d'albums
  • Sauvegarder les fichiers d'image
  • Sauvegarder les éléments de gestion des utilisateurs

Voyons comment on fait pour tout:

  • cd / ; /bin/tar -cjf /opt/backup/gallery_conf.tar.bz2 etc/gallery
  • cd /; /bin/tar -cjf /opt/backup/gallery_albums.tar.bz2 var/www/albums
  • inclus dans les albums
  • également inclus dans les albums (dans le répertoire caché /var/www/albums/.users) !

Automatisation de tout ça !

Maintenant que nous disposons de tout ce qu'il nous faut, autant automatiser cette tache pour ne pas l'oublier. Sous GNU/Linux, on utilise généralement une tache cron pour ça. Vu le peu de stress et d'activité d'un blog ou d'un site gallery, mon avis est qu'une sauvegarde par semaine sera largement suffisante.

Nous allons donc utiliser le script bash suivant pour la sauvegarde:

    #!/bin/sh
    # Script de sauvegarde de Serendipity et de Gallery
    #

    # Serendipity:
    echo '.dump' | sqlite3 /var/lib/dbconfig-common/sqlite3/serendipity/serendipity | bzip2 -c > /opt/backup/serendipity.sql.bz2
    cd / ; /bin/tar -cjf /opt/backup/serendipity_conf.tar.bz2 etc/serendipity
    cd / ; /bin/tar -cjf /opt/backup/serendipity_upload.tar.bz2 var/lib/serendipity/uploads

    # Gallery:
    cd / ; /bin/tar -cjf /opt/backup/gallery_conf.tar.bz2 etc/gallery
    cd /; /bin/tar -cjf /opt/backup/gallery_albums.tar.bz2 var/www/albums

Nous nommerons ce script /etc/cron.weekly/backup et nous n'oublierons pas de le rendre exécutable (sinon, il n'est pas lancé par cron): chmod 700 /etc/cron.weekly/backup.

Reste enfin à vérifier quand est lancée la sauvegarde hebdomadaire. Le fichier /etc/crontab nous permet de répondre à cette question:

    # /etc/crontab: system-wide crontab
    # Unlike any other crontab you don't have to run the `crontab'
    # command to install the new version when you edit this file
    # and files in /etc/cron.d. These files also have username fields,
    # that none of the other crontabs do.

    SHELL=/bin/sh
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

    # m h dom mon dow user  command
    17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
    25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
    47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
    52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Ce fichier nous montre que tous les scripts situés dans /etc/cron.weekly sont exécutés via run-parts (un script de lancement de scripts) à 6H47 tous les dimanches par défaut. Pour ma part, je préfère lancer tout ça le vendredi à 12H05. Voici donc ma ligne à moi: 05 12 * * 5 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )

Enfin, ne pas oublier de relancer le service cron (enfin je ne suis pas sur que cela soit nécéssaire mais dans le doute, ça ne coute pas grand chose): /etc/init.d/cron restart.

Récupérer la sauvegarde sur un ordinateur distant:

Nous venons d'automatiser la sauvegarde sur le serveur. Cette sauvegarde va nous permettre de remettre en fonctionnement le site assez rapidement en cas de corruption de données. Toutefois, si le disque du serveur crame, nous voilà dans de beaux draps...

Pour celà, on peut utiliser scp ou encore rsync. On peut imaginer d'autres solutions sur du téléchargement par http en mode sécurisé dont l'URL aurait été envoyée par email... On verra toutes ces solutions dans un prochain billet, c'est un autre projet.

Et la restauration ?

C'est très bien de récupérer des données, encore est-il plus intéressant de les restaurer en cas de besoin. Voici quelques commandes qui nous permettent d'aller plus vite:

Restauration:

  • Base de données de serendipity: rm -r /var/lib/dbconfig-common/sqlite3/serendipity/serendipity && bzcat /opt/backup/serendipity.sql.bz2 | sqlite3 /var/lib/dbconfig-common/sqlite3/serendipity/serendipity
  • Fichiers de config de serendipity: cd / ; /bin/tar -xjf /opt/backup/serendipity_conf.tar.bz2
  • Fichiers d'upload de serendipity:cd / ; /bin/tar -xjf /opt/backup/serendipity_upload.tar.bz2
  • Fichiers de conf de Gallery: cd / ; /bin/tar -xjf /opt/backup/gallery_conf.tar.bz2
  • Fichiers d'albums de Gallery: cd /; /bin/tar -xjf /opt/backup/gallery_albums.tar.bz2