Utilisateur d'origine : Pierre
Zimbra est presque parfait. Il intègre toutes les fonctionnalités qu'on attendrait d'un serveur mail. Seulement voilà, il faut bien vendre des licences, et, comme beaucoup de logiciels, il dispose d'une version "Premium". Ainsi, dans sa version open-source, Zimbra ne dispose d'aucun utilitaire de sauvegarde / restauration.
Une limite qui peut être contournée très simplement en sauvegardant le répertoire de travail de Zimbra, mais il ne faut pas le faire n'importe comment... Explications.
Objectif
L'objectif de ce tuto est de configurer une sauvegarde automatique du dossier /opt/zimbra sur un serveur distant et d'envoyer un rapport de sauvegarde par mail. Bien sûr, si vous souhaitez réaliser une sauvegarde uniquement locale, vous pouvez en adaptant les commandes qui suivront ; mais, tout l'intérêt d'une sauvegarde est de la faire sur une machine distante.
Nous utiliserons la commande rsync pour réaliser une sauvegarde différentielle, et donc ne pas avoir à transférer plusieurs Go à chaque sauvegarde.
Préparation de la machine distante
Dans mon cas, j'utilise un simple VPS hébergé par un hôte différent de celui qui héberge Zimbra, pour plus de sécurité. Ce VPS de sauvegarde dispose d'un serveur SFTP, ce qui me simplifie grandement la tâche.
Nous allons créer un utilisateur zimbra-backup avec comme répertoire principal /home/zimbra-backup/, qui sera alors le répertoire de sauvegarde de notre Zimbra. Cet utilisateur aura une clé SSH enregistrée, qui permettra à notre serveur en production de se connecter au serveur de sauvegarde automatiquement pour réaliser ladite sauvegarde.
Dans la suite de ce tutoriel, j'utiliserai le terme "Serveur de sauvegarde" pour désigner le serveur qui accueillera la sauvegarde, et "Serveur Zimbra" pour désigner le serveur hébergeant notre Zimbra en production.
Donc, sur notre serveur de sauvegarde, nous créons l'utilisateur et lui associons son répertoire par défaut :
adduser zimbra-backup --home /home/zimbra-backup/
Lors de la création de l'utilisateur, il vous est demandé de saisir un mot de passe. Définissez un mot de passe aléatoire, vous n'aurez normalement pas à l'utiliser étant donné que le serveur Zimbra s'authentifiera via une clé.
Par acquis de conscience, faites en sorte que le répertoire principal appartienne bien à l'utilisateur que l'on vient de créer, même si normalement c'est fait automatiquement :
chown -R zimbra-backup /home/zimbra-backup/
Passons désormais sur le serveur Zimbra. Nous allons générer une paire de clés (privée/publique) qui nous servira pour nous authentifier sur le serveur de sauvegarde :
ssh-keygen -t rsa
La commande vous demande de choisir un répertoire où sauvegarder la paire de clés. Mettez ce que vous voulez, mais notez ce répertoire. Ensuite, ne définissez pas de phrase de passe car la clé va être utilisée de manière automatique. Appuyez simplement sur entrée.
Nous avons alors généré une clé privée et une clé publique. Nous allons bientôt envoyer la clé publique sur le serveur de sauvegarde pour nous autoriser à nous connecter à ce dernier. Avant cela, je dois vous avertir une nouvelle fois qu'une clé privée ne doit jamais être communiquée à un tiers, et, dans la mesure du possible, ne doit jamais quitter le serveur (pas de transfert par FTP de la clé, pas de nano, rien, de toute façon il n'y a rien de très beau à voir).
Envoyons maintenant la clé publique sur le serveur de sauvegarde. Naviguez vers le répertoire dans lequel vous avez sauvegardé la paire de clés. Par défaut :
cd ~/.ssh
Dans ce répertoire, vous devriez avoir au moins trois fichiers :
id_rsa : Votre clé privée à garder pour vous. Si vous aviez saisi une phrase de passe lors de la génération, elle serait chiffrée.id_rsa.pub : Votre clé publique à communiquer à n'importe quel serveur qui devrait vous autoriser à entrerknown_hosts : Ce fichier ne nous intéresse pas ici, il contient la liste des fingerprints que votre serveur connaît
Si vous avez bien suivi ce que je raconte depuis quelques minutes, vous devriez savoir que nous allons envoyer le fichier id_rsa.pub sur notre serveur de sauvegarde. Pour ce faire, rien de plus simple :
ssh-copy-id -i id_rsa.pub zimbra-backup@xxx.xxx.xxx.xxx -p 22
Remplacez évidemment xxx.xxx.xxx.xxx par l'adresse IP de votre serveur de sauvegarde. Vous êtres invité à confirmer l'ajout du fingerprint du serveur distant (dans le fichier known_hostsjustement) puis à saisir le mot de passe de l'utilisateur zimbra-backup créé plus tôt. Et voilà, la clé est copiée sur le serveur distant !
Le script de sauvegarde
Passons aux choses sérieuses. Je vous propose de créer un dossier de travail et de commencer à écrire un fichier backup.sh :
mkdir backup_script
cd backup_script
nano backup.sh
Alors, comme tout bon script qui se respecte, vous devez commencer par indiquer le shell d'exécution du script. Puis nous allons partir sur une commande rsync toute simple que nous allons étoffer au fur et à mesure de ce tutoriel. Attention, n'exécutez pas encore ce script !
#!/bin/bash
rsync -e ssh -az --stats /opt/zimbra/ zimbra-backup@xxx.xxx.xxx.xxx:/home/zimbra-backup/ --delete
Décortiquons ensemble cette commande :
rsync est la commande de base, permettant de réaliser une sauvegarde différentielle-e ssh permet d'indiquer que la destination de la sauvegarde est un serveur distant, avec authentification via SSH-az permet d'activer la compression des fichiers pour que la sauvegarde se fasse plus rapidement--stats permet d'avoir des statistiques sur le transfert à la fin de celui-ci/opt/zimbra/ est notre répertoire sourcezimbra-backup@xxx.xxx.xxx.xxx:/home/zimbra-backup/ est notre répertoire destination, n'oubliez pas de remplacer les croix par l'adresse IP du serveur de sauvegarde--delete permet d'indiquer qu'il faut supprimer, sur le setveur de sauvegarde, les fichiers qui n'existent plus sur notre serveur Zimbra
Dans l'idée, cette commande pourrait fonctionner, mais si vous l'exécutez, vous allez voir qu'elle transfère environ 80Go pour une installation de Zimbra fraîche. Mais pourquoi ?
Sans rentrer dans les détails, ceci est dû à un fichier très particulier appelé sparse file. Ce fichier s'alloue 80Go de mémoire mais n'en occupe en réalité que quelques Mo. Le problème est que rsync gère mal ce type de fichier et va transférer 80Go de vide au lieu de re-créer un sparse file sur le serveur distant.
Nous allons donc ruser et compresser ce sparse file en un nouveau fichier, que l'on va stocker dans /opt/zimbra/backup_mail_files. La commande de compression va permettre de transformer notre sparse file en fichier normal, d'une taille normale. Ensuite, on exclut le sparse file de notre commande de sauvegarde.
#!/bin/bash
tar -PScf /opt/zimbra/backup_manual_files/data.mdb.tar /opt/zimbra/data/ldap/mdb/db/data.mdb
rsync -e ssh -az --stats --exclude 'data/ldap/mdb/db/data.mdb' /opt/zimbra/ zimbra-backup@xxx.xxx.xxx.xxx:/home/zimbra-backup/ --delete
Vous remarquerez l'ajout :
- La commande
tar permet de créer une copie de notre sparse file en fichier normal. Ce fichier est stocké dans un sous-répertoire de /opt/zimbra, donc rsync le sauvegardera bien. Je ne rentrerai pas dans les détails des options de cette commande, qui sont un peu complexes.
- De l'option
--exclude dans notre commande de sauvegarde, qui permet d'exclure un fichier (le sparse file). Sa copie sera bien sauvegardée étant donnée qu'elle a été créée dans /opt/zimbra/backup_manual_files/.
Dans l'absolu, le script pourrait être exécuté tel quel. Mais il manque quand même sacrément d'ergonomie, vous ne trouvez pas ? En début de tutoriel, je vous avais promis des rapports envoyés par mail, vous vous souvenez ? Voici comment nous allons procéder :
- Récupérer la sortie de l'ensemble des commandes dans un fichier
backup_mail
- Ajouter un petit header sympa avec la date et l'heure d'exécution
- Envoyer le contenu du fichier par mail à l'adresse de votre choix (personnellement, j'ai créé une adresse
backup@domain.tld sur mon zimbra et tous les rapports sont envoyés dessus)
Pour que vous compreniez ce qui va suivre, quelques petites astuces :
> permet d'orienter la sortie d'une commande vers un fichier, en effaçant tout son contenu antérieurement créé>> permet d'orienter la sortie d'une commande vers un fichier, à la suite de ce qui a été antérieurement créé2>&1 permet d'orienter la sortie des erreurs vers le fichier selon le précédent flux (je vous renvoie à un cours sur les flux si vous ne comprenez pas cela)
Voici donc notre script final :
#!/bin/bash
printf "Rapport de sauvegarde Zimbra du " > backup_mail
date "+%D %T" >> backup_mail
echo "-------------------------------------------------" >> backup_mail
tar -PScf /opt/zimbra/backup_manual_files/data.mdb.tar /opt/zimbra/data/ldap/mdb/db/data.mdb >> backup_mail 2>&1
rsync -e ssh -az --stats --exclude 'data/ldap/mdb/db/data.mdb' /opt/zimbra/ zimbra-backup@xxx.xxx.xxx.xxx:/home/zimbra-backup/ --delete >> backup_mail 2>&1
cat backup_mail | mail -s "Rapport de sauvegarde : $(date +%D)" backup@domain.tld
N'oubliez pas d'adapter :
- La ligne
rsync en précisant l'adresse IP de votre serveur de sauvegarde
- La dernière ligne en précisant l'adresse mail à laquelle vous souhaitez recevoir les rapports
Pour rappel, rsync utilisera la paire de clés générée précédemment pour s'authetifier sur le serveur de sauvegardes.
Automatisation
Vous pouvez évidemment lancer votre script à la main en tapant sh backup.sh, mais tout l'intérêt d'avoir fait un script est de pouvoir automatiser la tâche. Pour cela, nous allons utiliser notre fidèle cron. Pour le paramétrer, tapez la commande suivante :
crontab -e
Tout à la fin du fichier, nous allons ajouter les paramètres d'exécution de la commande, ainsi que la commande en elle même. Par exemple, j'ai choisi d'exécuter mon script tous les matins à 3h :
00 03 * * * sh /home/scripts/backup.sh
Pour en savoir plus sur cron, je vous renvoie vers ce cours.
Fermez le fichier, enregistrez, et voilà, votre sauvegarde est opérationnelle ! Notez que la première sauvegarde peut être très longue, et celle juste après une mise à jour de Zimbra également.
File has vanished
Si vous apercevez, dans votre rapport, des erreurs du type File has vanished, pas de panique. Il s'agit juste de fichiers temporaires que rsync n'a pas pu copier car ils ont été supprimés avant.
Restauration
Je ne vous le souhaite pas, mais, si un jour vous devez restaurer votre installation, il suffit d'exécuter rsync en sens inverse. N'obliez pas de décompresser le sparse file dans son répertoire originel !
