Des sauvegardes à la maison

November 28, 2010 by nono
Catégories geekeries - Mots-clés avahi backuppc libvirt sauvegardes zeroconf

Je suis administrateur système. Je sais faire des sauvegardes. Je sais même en ressortir des données en cas de besoin. Sauf que les systèmes « lourds » que j'utilise au boulot sont assez peu adaptés à un usage domestique.

J'ai (principalement) deux machines à la maison : un PC de bureau assez récent et raisonablement puissant et un petit serveur qui ronronne dans un coin (c'est lui qui héberge ce blog, entre autres). Pour le PC de bureau, pas de problème, je branche de temps en temps un disque externe et j'ai un bout de script à base de rdiff-backup qui fait le reste. Je pourrais faire de même pour le serveur ; je l'ai même fait pendant pas mal de temps. Sauf que le disque externe qui servait à ça a fini par devenir trop petit, alors que le disque interne de mon PC de bureau est presque vide. Le genre de problème qui a de quoi vous motiver un geek.

Une machine virtuelle

Pourquoi utiliser une machine virtuelle pour héberger mon serveur de sauvegardes, plutôt qu'héberger le service directement sur le PC ? Plein de raisons :

  • ça évite de tout casser lors des mises à jour (j'utilise une distribution Linux assez réputée dans ce domaine),
  • si j'ai besoin de tirer un peu sur le PC (pour faire du mixage audio par exemple), je peux arrêter la machine virtuelle et je suis sûr qu'une sauvegarde ne se déclenchera pas au mauvais moment,
  • j'avais envie de jouer avec KVM et avec la libvirt.

Bref, me voilà parti à jouer avec la couche de virtualisation de Fedora. Rien de bien sorcier : après un petit tour dans la doc, j'ai créé un groupe libvirt dans lequel j'ai ajouté mon compte et j'ai ajouté ou modifié les lignes suivantes dans /etc/libvirt/libvirtd.conf :

unix_sock_group = "libvirt"
unix_sock_rw_perms = "0770"
auth_unix_rw = "none"

Je peux maintenant lancer virt-manager en tant qu'utilisateur de base ; ensuite, il n'y a plus qu'à cliquer. J'ai donc créé une machine virtuelle appelée backuppc et j'y ai installé une Debian Squeeze.

BackupPC

J'ai ensuite installé l'excellent BackupPC dans la machine virtuelle en question. Opération très compliquée :

aptitude install backuppc

L'installeur du paquet Debian génère un mot de passe pour accéder à l'interface web de BackupPC ; il vaut mieux le garder sous le coude, il resservira plus tard.

À part ça, c'est prêt, BackupPC est installé et va maintenant sauvegarder automatiquement... bah, il va falloir lui dire quoi. Ça peut tout à fait se faire à l'ancienne en allant éditer la config dans le répertoire /etc/backuppc/. Comme j'avais envie de faire dans le high-tech et d'utiliser l'interface web, j'ai procédé autrement.

mDNS

À ma droite, une machine (virtuelle) qui obtient son adresse IP en DHCP (par dnsmasq). À ma gauche, un navigateur web. Comment leur apprendre à parler entre eux ? Mais c'est bien sûr, c'est un boulot pour mDNS !

Serveur : la machine virtuelle

De ce côté, pas grand chose à faire :

aptitude install avahi-daemon

Ça installe un serveur mDNS et ça lance tout ce qu'il faut comme il faut. Pour une fois que c'est Debian qui fait simple, ça mérite qu'on le souligne. :-)

Client : le PC sous Fedora

Sur le principe, c'est à peine plus compliqué :

yum install nss-mdns

Ça installe les bouts de résolveur qui vont bien et ça va éditer /etc/nsswitch.conf comme il faut. Dans le détail, ça se passe sur cette ligne :

hosts:      files mdns4_minimal [NOTFOUND=return] dns

Ce qui est important, c'est mdns4_minimal ; ça veut dire « quand tu veux résoudre un nom qui se termine par .local, va voir si des fois il n'y aurait pas une adresse IPv4 annoncée en mDNS pour aller en face. Pourquoi seulement .local ? Simplement pour éviter les timeouts. Si vous y tenez, vous pouvez remplacer mdns4_minimal par mdns4 pour changer ce comportement, mais ne venez pas vous plaindre ensuite que vous avez transformé votre PC formule 1 en char à boeufs. Pourquoi seulement en IPv4 ? Parce qu'en IPv6, sur les sous-réseaux sans routeur (ce qui est par défaut le cas du réseau virtuel géré par la libvirt), vous ne récupérerez que des adresses lien-local qui ont des chances d'être inutilisables.

Mais alors, maintenant, si je tape host backuppc.local, ça va me renvoyer l'adresse IP de ma machine virtuelle ? Hé non, tout simplement parce que la commande host fait directement une résolution DNS sans passer par NSS. Dommage, c'était bien essayé.

Mais alors, maintenant, si je tape ping backuppc.local, ça va marcher ? Hé non, mais là c'est plus embêtant. Après enquête rapide, c'était la faute au pare-feu de la machine hôte qui bloquait le port UDP 5353 (celui ou les échanges mDNS passent sur le groupe multicast 224.0.0.251). Une fois le dit port ouvert, ça devrait mieux marcher.

Mais alors, maintenant... ? Non, toujours pas. Parce que quand la libvirt configure le pont virtuel virbr0 où les machines virtuelles invitées sont accrochées par défaut, elle configure une NAT sur tout ce qui sort du port en question (bien), et que la NAT en question ratisse un peu trop large et touche à la source des paquets multicast. En quoi c'est grave ? Ça change le port source des paquets mDNS, qui devrait toujours être le port UDP 5353. Et ça déplait profondément à Avahi (l'implémentation de mDNS la plus courante sous Linux). Et comme les choses sont bien faites, la libvirt ajoute ses règles avant celles qui sont déjà configurées (pas moyen donc d'ajouter explicitement une exception dans la config iptables de la machine) et les règles en question sont en dur dans son code (bande de cons).

Une lueur d'espoir : les versions récentes de la libvirt disposent de hooks qui permettent de lui faire exécuter nos propres scripts. Sauf que manifestement le script daemon est exécuté avant la mise en place des règles iptables, ce qui ne nous aide pas. La seule solution que j'ai trouvée est d'ouvrir le pare-feu dans le script qemu, ce qui marche mais qui n'est pas propre (ça va insérer la même règle une fois pour chaque machine virtuelle lancée). Au final ça donne un script /etc/libvirt/hooks/qemu qui ressemble à ça :

#!/bin/sh

PATH=/sbin:/usr/sbin:/bin:/usr/bin

if [ "$2" = "start" ]
then
        iptables -t nat -I POSTROUTING 1 -d 224.0.0.0/4 -j RETURN
fi

if [ "$2" = "shutdown" ]
then
        iptables -t nat -D POSTROUTING -d 224.0.0.0/4 -j RETURN
fi

Apparemment il y a moyen de faire à peu près la même chose avec le driver de filtre réseau de la libvirt, mais ça reste lié à chaque machine invitée plutôt qu'à l'hôte lui-même.

Une fois que tout ce bazar est en place, ça finit par tomber en marche :

arnaud@carrosse:~% getent hosts backuppc.local
192.168.122.231 backuppc.local

Yapluka !

Ça y est, c'est prêt, l'interface web de BackupPC est accessible à l'adresse http://backuppc.local/backuppc/. Le login de l'administrateur est backuppc, est le mot de passe est celui dont il était question quelques paragraphes plus haut. L'interface web permet d'éditer directement la config du serveur, y compris la liste des machines à sauvegarder.

Pour ma part, j'utilise la méthode de sauvegarde rsync qui s'appuie sur rsync (on l'aurait deviné) et ssh. Il faut donc que l'utilisateur backuppc de la machine virtuelle ait le droit de se connecter en ssh aux machines à sauvegarder, sous un compte ayant assez de droits pour lire tout ce qui doit être sauvegardé et écrire tout ce qui doit être restauré. Pour ma part j'utilise le compte root ; il y a sûrement moyen d'affiner un peu, mais dans mon cas ça ne vaut pas le coup (ça concerne tellement de fichiers qu'un utilisateur qui y a accès pourra de toute façon tout casser, root ou pas). Sur la machine virtuelle, donc :

su - backuppc
ssh-keygen -t rsa
(laisser la passphrase vide)
ssh-copy-id root@monserveur

En cliquant dans l'interface, j'ai généré un fichier de config pour la machine à sauvegarder qui ressemble à ça :

$Conf{RsyncShareName} = [
  '/etc',
  '/var/www/html',
  '/home'
];
$Conf{XferMethod} = 'rsync';

Ce fichier s'appelle /etc/backuppc/lenomdelamachine.pl ; vous pouvez bien sûr l'éditer avec votre vi favori, mais si vous retournez cliquer dans l'interface il se peut que vous perdiez vos modifs si elles sont un peu trop compliquées pour l'éditeur de config. À manier avec précaution donc.

Conclusion

J'ai juste décrit les grandes lignes de ma config, ce blog n'est pas vraiment le lieu pour réécrire la doc de BackupPC ; je vous encourage tout de même à vous plonger dans le logiciel, sous des apparences un peu rustiques il s'avère excellent pour ce qu'il sait faire, c'est à dire sauvegarder des « petites » machines, y compris des portables (mais pas des gros serveurs, pas qu'il ne sache pas faire, mais ça demande une machine de sauvegarde puissante et dotée d'un stockage performant). Dans un autre contexte, je l'utilise pour sauvegarder plusieurs dizaines de postes de travail et il donne toute satisfaction.