Solutions de backup

On m'a demandé de partager mon script de backup gmail donc je vais le poster ici. Par contre je précise que c'est à l'usage de personnes qui ont déjà le niveau suffisant en admin système ; je vais essayer de donner un maximum d'indications en plus du script, mais ensuite je ne répondrais à aucune question ou demande de support hein.

Donc, le script tourne sur une Debian Lenny et il faut installer deux trois trucs qui ne sont peut-etre pas sur une fresh install :
- shareutils pour le uuencode
- gnupg
- mysqldump

Il faut également renseigner les variables de config correctement (voir le script)

Pour gpg, il faut stocker sa passphrase dans /root/.gnupg/passphrase

Il est possible de faire un "touch .NO_BACKUP" dans les répertoires qui pourraient être inclus dans le backup mais que l'on veut exclure (des exceptions quoi)

Pour le reste, voir le script (bon courage)...

Perso, j'ai mis le script en owner root et permission 0700 et j'ai ajouté cette ligne dans la crontab du root :

0 2 * * * nice /root/backup-gmail.sh > /root/backup-gmail.log

#!/bin/sh

# If postfix errors: postconf -e message_size_limit=0

# Passphrase in /root/.gnupg/passphrase

# Exclude some directories with a blank .NO_BACKUP file inside

# Needed: sharutils gpg mysqldump

# To restore: cat FILES.gpg-* | gpg -d --cipher-algo AES256 --passphrase-fd 3 3< /root/.gnupg/passphrase | tar -xz



# BEGIN CONFIG



MYSQL_USER=XXXX

MYSQL_PASSWORD=XXXX



EMAIL=XXXX@gmail.com

SUBJECT_PREFIX="[BACKUP-SERVER]"

ATTACHEMENT_MAX_SIZE=20M



DIRS="/var/www/*/www /home/* /etc /root /var/www/default"

TAR_EXCLUDE="*/wp-content/plugins/hyper-cache/cache/*"



# END CONFIG



DATE=`date +"%d-%m-%Y"`



echo == databases



mysqldump --all-databases --hex-blob --set-charset -u$MYSQL_USER -p$MYSQL_PASSWORD | gzip -c | gpg -c -q --batch --yes --cipher-algo AES256 --passphrase-fd 3 3< /root/.gnupg/passphrase | split -b $ATTACHEMENT_MAX_SIZE - "databases.gz.gpg-"



for file in databases.gz.gpg-*; do

        ls -l $file 

        cat $file | uuencode $file | mail -s "$SUBJECT_PREFIX databases ($DATE)" $EMAIL

        rm $file

done



exclude=""



for dir in $TAR_EXCLUDE; do

        exclude="$exclude --exclude=$dir"

done



for dir in $DIRS; do

        if [ -d $dir ] && [ ! -e $dir/.NO_BACKUP ]; then

                echo == $dir



                basename=`basename $dir`

                dirname=`dirname $dir`

                archivename=${dir#/}

                archivename=${archivename////-}



                tar -C $dirname -czp $exclude $basename | gpg -c -q --batch --yes --cipher-algo AES256 --passphrase-fd 3 3< /root/.gnupg/passphrase | split -b $ATTACHEMENT_MAX_SIZE - "$archivename.tgz.gpg-" 



                for file in $archivename.tgz.gpg-*; do

                        ls -l $file

                        cat $file | uuencode $file | mail -s "$SUBJECT_PREFIX $dir ($DATE)" $EMAIL

                        rm $file

                done

        fi

done



exit 0

Je reviens sur ce topic pour parler de btrfs, le système de fichier Linux sensé remplacer ext4 et fourni avec Debian 6. Une des particularités de ce système est de permettre de faire des snapshots. J'ai ajouté un disque btrfs sur une machine de sauvegarde.

Contrairement à rsnapshot qui se contente de faire des hardlink entre les fichiers identique, btrfs n'écrit que les différences (en fait les blocs différents). Donc pour une sauvegarde de base de données de plusieurs giga, on gagne sans doute beaucoup. Et comme c'est intégré au système de fichier, le snapshot est immédiatement exploitable.

J'ai fait un petit script pour gérer les backup et en quelques lignes on a quelque chose de plus performant et plus pratique que rsnapshot. Pour l'instant les résultats sont tout à fait bons.

De façon général, je n'ai pas remarqué de soucis avec ce FS mis à part qu'on ne peut pas booter dessus et qu'on ne peut pas l'utiliser comme swapfile. Il y a des fonctionnalités intéressantes comme la possibilité d'ajouter et supprimer des disques au système de fichier mais je n'ai rien testé de tout ça.

ZFS, à moins de changer de licence, ne sera jamais intégré dans Linux autrement que par FUSE.

Je ne vois pas en quoi ZFS a plus d'avenir que BTRFS. Des distributions ont déjà prévu de mettre BTRFS comme système de fichier par défaut. Il va se constituer une communauté bien plus importante autour de BTRFS. BTRFS s'intègre bien comme suite aux extX sous Linux et il propose un outil de conversion des partitions ext2/ext3/ext4 vers BTRFS que j'ai testé et qui marche très bien.
Il n'existe plus de concurrent réel, le plus solide était ReiserFS 4 qui ne sortira jamais.
Tout ça m'amène a penser que d'ici 2 à 5 ans, on aura du BTRFS partout et du ZFS que sur les environnement Sun ou pour des besoins particuliers (ZFS est endian-independant).

J'ai testé ZFS (sur Debian/kFreeBSD) et je n'ai pas vraiment été épaté. De ce que j'ai vu, testé et compris le système multi-disque de BTRFS est bien plus pratique à utiliser et maintenir que celui de ZFS.

Quelques infos:
http://www.codestrom.com/wandering/2009/03/zfs-vs-...
http://linuxupdate.blogspot.com/2009/01/btrfs-next...