Sauvegarde d'un serveur virtuel VMWare à chaud avec rsync

Le but est de sauver un serveur virtuel sur une machine unix distante sur laquelle on a accès à cron.
Je me place aussi dans l'hypothèse où je fais une copie directe du serveur virtuel (le guest). On pourrait envisager d'en faire au préalable une archive, de la compresser et de la déplacer, mais l'avantage de copier le guest tel quel via rsync permet de limiter les volumes échangés si le guest est faiblement utilisé et surtout permet de le copier dans un nouvel environnement vmware par exemple, prêt pour redémarrage le cas échéant (à la configuration des interfaces réseau près).

Dans la suite, j'appelerai 'local' la machine unix sur laquelle je vais importer une copie du guest et 'distant' la machine host sur laquelle tourne le guest dans un environnement vmware. Rsync doit être installé sur ces deux machines.

Il faut au préalable créer un compte qui aura accès en lecture aux fichiers représentant le guest sur la machine host distante vmware. J'appelle ce compte 'sauveguest'. Tout est détaillé ci-dessous.

Les fichiers du guest sont situés sur le host dans l'arborescence vmware par défaut, mais selon votre installation de vmware, ils peuvent se trouver ailleurs.

Sur la machine distante host, en tant que root ou sudoer

adduser sauveguest
cd /usr/local/soft/vmware/vmware/nomduguest
chmod a+r *
Ce n'est pas la solution la plus propre. Peut-être faudrait-il créer un groupe contenant sauveguest et le groupe d'appartenance initial des fichiers -groupe root, chez moi- et faire un chgrp de tous les fichiers ?

Sur la machine locale en tant que soi-même (ex : jerome dans /home/jerome), sauf si déjà fait, on crée une paire de clés qui vont servir à rsync pour une connexion ssh sans mot de passe. Puis, on copie la clé publique dans l'environnement de sauveguest sur la machine distante :

ssh-keygen -d              # laisser les chemins par défaut dans les questions
scp .ssh/id_dsa.pub sauveguest@distant:./.ssh/

A nouveau sur la machine distante, en tant que sauveguest, on ajoute la clé de la machine locale dans le fichier des clés autorisées :

mkdir .ssh
chmod 700 .shh
cd .ssh
touch authorized_keys
chmod 600 authorized_keys
cat id_dsa.pub >> authorized_keys
rm id_dsa.pub

Enfin, sur la machine locale, en tant que soi-même, on crée le script de sauvegarde par rsync.
J'ai décidé de tout sauver dans un répertoire sauveguest de /home/jerome.
Le script sera lancé par cron qui ne connait pas l'environnement (path, etc) : l'idéal est donc de n'écrire que des chemins absolus, même pour les commandes.
Par ailleurs, je fais un "su - jerome" pour que l'environnement de stockage de mes clés ssh soit disponible et je passe par l'option "-c" la commande rsync.

mkdir sauveguest
vi sauveguest.sh
> su - jerome -c "/opt/csw/bin/rsync -avz sauveguest@distant:/usr/local/soft/vmware/vmware/nomduguest/ /home/jerome/sauveguest/"
> :wq
chmod a+x sauveguest.sh # faire la sécurité plus finement ultérieurement là

Toujours sur la machine locale, en tant que root, on édite la crontab et on ajoute le script à 1h00 du matin tous les jours par exemple (chaque colonne de valeur est séparée de l'autre par un espace dans le fichier crontab) :

bash
export EDITOR=vi # ces deux lignes précédentes ne me sont nécessaires que parce que je suis sous solaris 10
crontab -e
>00 1 * * * /home/jerome/sauveguest.sh > /home/jerome/sauve.log
>:wq
Et voilà, c'est fini.

J'ai testé une récupération à partir de cette sauvegarde en spécifiant de conserver l'UUID du serveur virtuel dans VMWare (sur une autre plateforme host VMWare que celle d'origine) et ça fonctionne parfaitement. J'ai eu un bug en demandant de générer un nouvel UUID (sur la plateforme host d'origine, mais c'est peut-être lié à un conflit car le guest sauvé tourne en parallèle sur la plateforme).
Lors d'une récupération, pensez évidemment à tout mettre sous root sur la machine host qui va accueillir le guest récupéré :

chown root:root * # dans le répertoire des fichiers du guest. Ce répertoire doit lui même être root:root
Comments