Utiliser un Raspberry Pi comme serveur de backup


Salut à tous ! Je vais aujourd’hui, vous introduire une utilisation plutôt sympathique réalisable avec un Raspberry Pi. En effet, il s’est avéré que celui-ci était relativement lent, dans sa fonction précédente, à savoir l’exécution d’un serveur web… Dans un même temps, le script de backup que j’avais écrit a rapidement montré ses limitations : nous n’avons qu’un espace de stockage très restreint, la gestion des sauvegardes incrémentale était impossible, la restauration d’un unique élément fastidieuse, et en plus, c’était NSA compliant.
Bref, l’idée à présent est donc d’utiliser un disque dur externe branché à un Raspberry pour le transformer en véritable outil de backup. C’est une solution à bas cout, et plutôt efficace pour le moment.

Sommaire :

Le boitier 2.0

Il est avant tout temps d’upgrader notre boitier, pour que celui-ci permette à notre disque dur d’y prendre également place. :p Attention à ne pas oublier l’aération, comme je le fais avec mes trous partout : le disque devient facilement très chaud quand il a à écrire une dizaine de go d’une seule traite. De même, son alimentation doit s’effectuer via une source extérieure et non pas par le câble USB. Si c’est le cas, il faudra utiliser un hub auto alimenté si vous ne voulez pas griller votre Raspi, car celui-ci ne peut transporter tellement d’énergie.

boite_ouverte

Préparation de Raspbian

Je vous conseille d’utiliser Raspbian comme distribution. Elle fonctionne, en effet, très bien pour notre tâche. Une fois l’archive téléchargée, copions-la sur la carte mémoire à l’aide de l’outil dd :

[spydemon@Myrphak][~/dowloads]% atool -x 2013-09-25-wheezy-raspbian.zip 
Archive:  2013-09-25-wheezy-raspbian.zip 
  inflating: Unpack-0566/2013-09-25-wheezy-raspbian.img  
2013-09-25-wheezy-raspbian.zip: extracted to `2013-09-25-wheezy-raspbian.img' 

[spydemon@Myrphak][~/dowloads]% sudo dd if=2013-09-25-wheezy-raspbian.img of=/dev/mmcblk0 
[sudo] password for spydemon: 
5785600+0 enregistrements lus 
5785600+0 enregistrements écrits 
2962227200 octets (3,0 GB) copiés, 1176,86 s, 2,5 MB/s 

Une fois tout ça terminé, vous pouvez essayer de booter sur le Raspi avec la carte mémoire, fraichement réécrite. Si tout se passe correctement, vous devriez avoir un menu de présentation avec plusieurs choix, comme vérifier l’intégrité du système, changer le mot de passe de l’utilisateur Pi, etc. Félicitation ! Cette première étape a été réalisée avec succès. 🙂 (Si vous avez un kernel panic, rien du tout, ou encore, la télé qui explose, je ne vous cache pas que c’est plutôt mauvais signe…)

Préparation du disque dur externe

C’est la troisième carte mémoire que je crame avec mon Raspi, malgré les protections en écriture…
Pour éviter d’en massacrer une nouvelle en deux mois, j’ai décidé de mettre sur le disque dur un maximum de choses de façon à la solliciter le moins possible. La partition /boot étant le seul élément nécessaire sur la carte car le firmware du Raspi ne supporte que cette option, on exportera tout le reste.

Pour cela, il faut prévoir au moins deux partitions sur notre disque dur externe : une pour le swap, et l’autre pour la racine /. Comme on fait les choses bien ici, on va aussi splitter / et /home. La seconde contiendra les données brutes de nos sauvegardes. Il peut en effet, être intéressant de les isoler du système, dans le cas ou l’on déciderait de changer celui-ci, ou bien simplement pour plus de sécurité (on pourrait envisager de mettre cette partition en RAID, ou sur un disque réseau.).
Voilà donc à quoi devrait ressembler la table de vos partitions, après les formatages adéquat :

J'ai 15 Go d'utilisés dans /home car j'ai déjà mis en place mon service de backup. Ouais je sais, je suis un tricheur.
J’ai 15 Go d’utilisés dans /home car j’ai déjà mis en place mon service de backup. Ouais je sais, je suis un tricheur.

La dernière étape de cette partie consiste à transférer les données correspondantes à votre système d’exploitation de la carte, au disque. Si vous laissez votre racine vide, vous aurez bien évidemment quelques problèmes. 😉

[spydemon@Myrphak][~] sudo mount /dev/mmcblk0p2 /mnt/one
[spydemon@Myrphak][~] sudo mount /dev/sdc1 /mnt/two
[spydemon@Myrphak][~] sudo cp -R /mnt/one/* /mnt/two

Configuration des points de montage

À présent, il va falloir « dire » au Raspi qu’on aimerait bien qu’il utilise la partition système sur notre disque dur externe plutôt que celle présente sur la carte mémoire. Pour ce faire, rebranchez la carte à votre ordinateur, et montez la première partition (celle de 50 Mo, normalement trouvable sous /dev/mmcblk0p1). C’est ici que se situent les bootloaders, par lesquels nous avons à passer. Dans la configuration, nous avons le document cmdline.txt qui contient différents attributs nécessaires à l’exécution du noyau Linux. Nous allons nous intéresser à root, qui indique l’emplacement de la racine à utiliser. Nous avons plus qu’à modifier la valeur pour y mettre celle de notre disque à la place. Faites aussi attention à correctement remplir rootfstype, avec le bon système de fichier.

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/sda1 rootfstype=ext3 elevator=deadline rootwait 

On ne devrait pas se contenter d’indiquer des points de montage relatif à la configuration actuelle des périphériques externes. C’est-à-dire que des choses comme /dev/sda1 sont à éviter. Imaginez que vous branchiez une autre masse de stockage sur votre Raspi, et que celle-ci prenne la valeur de sda à la place du disque contenant le bon système de fichier… Vous n’allez pas aimer !
Pour ce faire, nous devrions plutôt utiliser les uuid, qui sont des identifiants uniques générés pour chaque partition. Pour trouver ces fameux attributs, il suffit de se rendre dans le dossier virtuel /dev/disk/by-uuid pour les obtenir à l’aide des liens symboliques présents.

[spydemon@Myrphak][/dev/disk/by-uuid]% ls -lh 
total 0 
lrwxrwxrwx 1 root root 15 12 nov.  14:03 2654-BFC0 -> ../../mmcblk0p1 
lrwxrwxrwx 1 root root 10 12 nov.  14:54 2af35d33-d94d-40eb-a846-6f05a50f5ad8 -> ../../sdc3 
lrwxrwxrwx 1 root root 10 12 nov.  14:54 4b946c25-a4fb-48be-ada3-7e834bb15407 -> ../../sdc2 
lrwxrwxrwx 1 root root 15 12 nov.  14:03 548da502-ebde-45c0-9ab2-de5e2431ee0b -> ../../mmcblk0p2 
lrwxrwxrwx 1 root root 10 12 nov.  14:37 562c0240-d8fc-4acd-a84d-b399bf3f83d1 -> ../../sdc1 
[…]

Malheureusement, j’ai l’impression que notre système de boot ne supporte pas ce genre de choses, il va donc falloir se contenter des attributs relatifs, et faire avec ce problème de stabilité.

Une fois arrivé à ce stade, seule la première partition de la carte mémoire sera utile (eh oui, c’est bien con d’avoir une carte de 8 Go, alors que seulement 50 Mo sont nécessaires, hein?). Il ne reste plus qu’à configurer notre fstab pour que les partitions swap et home soient montées correctement. Bon, on n’a plus d’excuses pour ne pas employer les uuid à cette étape. :p Éditez donc le fichier /etc/fstab d’une façon ressemblante à celle-ci :

# /etc/fstab: static file system information. 
# 
# Use 'blkid' to print the universally unique identifier for a 
# device; this may be used with UUID= as a more robust way to name devices 
# that works even if disks are added and removed. See fstab(5). 
# 
#                                                               
# / was on /dev/mmcblk0p2 during installation 
UUID=562c0240-d8fc-4acd-a84d-b399bf3f83d1       /               ext3    noatime,errors=remount-ro     0       1 
UUID=2af35d33-d94d-40eb-a846-6f05a50f5ad8       /home           ext3    noatime,errors=remount-ro     0       1 
# /boot was on /dev/mmcblk0p1 during installation 
UUID=2654-BFC0                                  /boot           vfat    utf8                          0       0 
# swap was on /dev/mmcblk0p2 during installation 
UUID=4b946c25-a4fb-48be-ada3-7e834bb15407       none            swap    sw                            0       0 
tmpfs                                           /tmp            tmpfs   defaults, noatime, mode=1777  0       0 

Bien sûr, il faudra que vous changiez les uuid en fonction des vôtres, et que vous fassiez gaffe au format du système de fichier. On notera aussi que la partition /boot correspond à celle présente sur notre carte mémoire (qui elle, doit être obligatoirement en FAT pour être lisible par le Raspi). Pour les options, j’ai choisi d’utiliser l’attribut noatime qui permet de ne pas mettre à jour la date du dernier accès aux fichiers. Du coup, nous ne respectons plus la norme POSIX, mais ça soulagera le petit processeur et pourra peut-être allonger un peu la durée de vie de notre disque dur.
errors=remount-ro, quant à lui, indique que le système de fichier doit être remonté en lecture seule, si un échec a eu lieu lors du premier montage. Ça permettra potentiellement de limiter la casse.

Configuration du réseau

Bien qu’il ne soit pas obligatoire, il est préférable d’attribuer une adresse IP fixe au serveur dans son sous-réseau (ça le devient si nous voulons pouvoir profiter du service Web fourni depuis l’extérieur). Pour se faire la configuration de /etc/network/interface présente dans l’article précédent est toujours encore suffisante :

# This file describes the network interfaces available on your system 
# and how to activate them. For more information, see interfaces(5). 

# The loopback network interface 
auto lo 
iface lo inet loopback 

# The primary network interface 
auto eth0 
iface eth0 inet static 
        address 192.168.1.26 
        netmask 255.255.255.0 
        gateway 192.168.1.1 

Rappelez-vous juste qu’il faut donner une adresse IP en dehors de celles susceptibles d’être allouées automatiquement par le démon DHCPD de votre routeur.

Le logiciel que j’ai choisi pour accomplir les backups n’est autre que BackupPC. Pour moi, il a plusieurs avantages comme la simplicité de son installation, le serveur Web de monitoring et d’administration “out of the box”, et surtout, le fait qu’il ne nécessite rien sur les clients. En effet, la méthode de copie des fichiers est très simple et bien connue des unixiens, car il ne s’agit que d’utilisations de rsync.

Du coup, tout ce dont a besoin BackupPC est ssh, pour établir la connexion, et bien évidemment rsync, pour effectuer le téléchargement. Par contre, le sens de communication est contraire à l’ordre « normal ». C’est ici le serveur qui prendra l’initiative de démarrer un backup en initialisant un échange avec le client. Les rôles techniques des entités sont donc en fait inversés.

Le principal ennui que constitue ce comportement réside dans le fait qu’il sera au client de se rendre accessible par le serveur de backup, et non l’opposé. Ce n’est pas un problème particulier si les seules machines à gérer sont à une place fixe dans un sous-réseau sur lequel nous avons pleinement la main, comme dans un datacenter. Par contre, les choses deviennent un peu plus complexes quand c’est un ordinateur portable que nous avons à protéger. Pour que celui-ci soit atteignable, il sera obligatoirement nécessaire de, par exemple, configurer le NAT statique sur la « Box » par laquelle on passe, sans oublier aussi qu’il faudra être en possession de la bonne IP publique… Bref, il s’agit clairement du gros point noir de BackupPC pour moi, parce que la protection d’éléments mobiles ne pourra forcément jamais être assurée à 100 %. Cependant, BackupPC gère très bien le fait qu’une machine ne soit pas joignable à un moment donné. C’est en effet sans encombre que le logiciel testera à nouveau l’accessibilité plus tard (vive ICMP) et lancera le backup dès que le client redonnera signe de vie. Ce comportement nous autorise donc à continuer à considérer cette solution comme fiable si l’on a la possibilité de nous connecter à intervalle relativement proche à un sous-réseau que l’on contrôle, comme le Net d’à la maison. 🙂

Installation et configuration de BackupPC

Il est temps de passer à la partie logicielle. L’installation de BackupPC est très rapide, car celui-ci se trouve dans les dépôts officiels. Un simple apt-get install backuppc fera donc l’affaire. 🙂 Toute la configuration se situe dans /etc/backuppc. Je vous invite à vous y rendre, et à remplir le fichier htpasswd contentant les identifiants des personnes ayant accès à l’interface d’administration Web. Pour l’écrire, je vous conseille d’utiliser le script htpasswd, fourni avec Apache (fourni avec BackupPC).

root@Framboise:~# htpasswd -cb fichier pseudo mot_de_passe 
Adding password for user pseudo 
root@Framboise:~# cat fichier 
pseudo:$apr1$2nHY4dWv$6Yt0x3LW62FFjSAbfnZjk0 

Le second truc à savoir est que les sauvegardes seront toutes enregistrées dans le répertoire /etc/backuppc/pc. Comme on aimerait plutôt mettre ces informations dans /home, la partition que l’on a spécialement créée pour ce but,nous pouvons effectuer un lien symbolique entre les deux emplacements. 🙂

root@Framboise:~# ln -s /etc/backuppc/pc/ /home/backuppc/ 

Et voilà ! Il ne reste plus qu’à relancer BackupPC, nous rendre sur l’interface Web, à l’adresse : http:///backuppc, et de se loguer avec les identifiants que vous venez de créer dans le fichier htpasswd.

root@Framboise:~# /etc/init.d/backuppc restart 
[ ok ] Restarting backuppc.... 
root@Framboise:~#

BackupPC_webInterface

Une fois loggué sur l’interface Web, il serait bien de mettre en place notre configuration par défaut. Pour ce faire, cliquez sur “Edit Config”, dans le menu à gauche, puis sur “Xfer” et enfin, modifiez les éléments suivants (dans la mesure où vos clients seront principalement sous Linux et que l’utilisation de rsync vous convienne) :

  • XferMethod : rsync
  • XferLogLevel : 1
  • RsyncShareName : / (Je n’ai pas bien compris à quoi ça correspond)
  • Dans la partie Include / Exclude, c’est à vous d’indiquer ce que vous voulez sauvegarder comme répertoire, par défaut.
  • RsyncClientPath : /usr/bin/rsync
  • RsyncClientCmd et RsyncClientRestoreCmd : $sshPath -q -x -l backup $host %rsyncPath $argList+
      Pour ce dernier champ, il ne s’agit en fait que de la commande à effectuer pour le backup.

    • -q est l’option qui permet à ssh d’être en mode silencieux. En effet, le texte retourné par celui-ci sera mal interprété par BackupPC, qui des fois réagit bizarrement.
    • -x désactive le forward X11, donc la session graphique (on ne sait jamais hein. ^^)
    • -l backup correspond au nom d’utilisateur avec lequel BackupPC doit se connecter sur le client, compte qu’on devra évidemment créer.
    • Enfin, la fin de la chaine indique l’IP du client, l’emplacement du programme rsync et ses arguments.

C’est tout ce qu’on a à configurer ici normalement. Vous pouvez donc sauvegarder les réglages. Il ne reste plus qu’à aller dans l’onglet “edit host” pour ajouter les adresses des machines que nous voulons protéger. 🙂 Attention au champ User, soit je me débrouille comme un gland, soit je n’ai pas compris à quoi il correspond, car je n’ai pas réussi à le mettre en relation avec le login à utiliser lors de la connexion ssh… Je vous conseille du coup d’y écrire la même valeur que celle que vous avez renseignée dans la chaine RsyncClientCmd précédemment.

C’est basiquement les grandes lignes de la configuration du serveur. Peut-être voudriez-vous un peu plus vous attarder sur les fréquences des backups, ou la gestion des emails de notification à envoyer, ou encore sur d’autres aspects. Je vous propose donc de vous promener dans l’interface Web qui me semble assez complète, ou de rechercher des infos sur Internet, car il y en a pas mal.

Configuration des clients

Avant tout, il faut créer le compte backup sur tous les clients. Ce sera, bien évidemment, notre point d’entrée sur la machine de notre serveur. 🙂 Inutile de dire que celui-ci devrait avoir un accès en lecture, voir en écriture (pour permettre les restaurations) à toutes les données qu’on souhaite protéger. On comprend vite en quoi cette caractéristique peut être critique… Si vous effectuez un backup bare métal d’une installation, le compte aura tout simplement un accès root à l’ordinateur. Pas cool, n’est-ce pas ? Je proposerai dans la dernière section, des moyens pour limiter les risques.

Comme expliqué précédemment, le serveur se connectera au client via ssh. Il faut donc générer une paire de clefs RSA pour celui-ci afin de permettre une authentification automatique sans avoir besoin d’un quelconque mot de passe à entrer. Pour la même raison, il est important de ne pas, non plus, protéger notre clef avec une phrase de passe.

root@Framboise:~# su backuppc 
$ cd ~ 
$ ssh-keygen 
Generating public/private rsa key pair. 
Enter file in which to save the key (/var/lib/backuppc/.ssh/id_rsa): 
Created directory '/var/lib/backuppc/.ssh'. 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /var/lib/backuppc/.ssh/id_rsa. 
Your public key has been saved in /var/lib/backuppc/.ssh/id_rsa.pub. 
The key fingerprint is: 
b3:42:ad:a8:b3:f4:95:07:92:6a:c8:d6:9c:e9:b8:bb backuppc@Framboise 
The key's randomart image is: 
+--[ RSA 2048]----+ 
|                 | 
|                 | 
|                 | 
|     . .         | 
|    o o S        | 
|..o.o+ + o       | 
|.o+=. = o        | 
|.o+o . o         | 
| E*+.            | 
+-----------------+ 

Une fois vos clefs générées, il faut envoyer la partie publique à tous les clients. Le script ssh-copy-id peut vous aider dans cette tâche. Attention à bien vous connecter la première fois sur chaque client à la main depuis le compte utilisateur de BackupPC de telle façon à ce que vous pouvez ajouter l’emprunte ECDSA de l’host dans votre fichier known_hosts à la main. À nouveau, BackupPC prend assez mal le fait de se retrouver face à cette demande. ^^

$ ssh backup@spyzone.fr 
The authenticity of host '[spyzone.fr] ([91.121.7.90])' can't be established. 
ECDSA key fingerprint is 43:ca:f2:81:68:31:e9:6f:f2:21:12:3a:a2:09:96:46. 
Are you sure you want to continue connecting (yes/no)? yes 
Warning: Permanently added '[spyzone.fr],[91.121.7.90]' (ECDSA) to the list of known hosts. 

Normalement maintenant, votre installation devrait être fonctionnelle. 🙂 Bon, je vous avoue que je rédige cet article un peu tardivement par rapport au moment où j’ai fait l’investigation nécessaire pour pouvoir réellement implémenter ce processus. J’ai peut-être oublié quelques étapes subtiles… N’hésitez pas à me contacter si quelque chose coince chez vous, il existe toujours une solution. 🙂

Amélioration de la sécurité des comptes de backup

Comme dit précédemment, si pour une raison quelconque quelqu’un s’empare de votre serveur de backup, cette personne pourrait avoir accès à l’intégralité de votre parc… Bref, vous passerez probablement une mauvaise journée. Pour limiter les dégâts, on peut faire plusieurs choses.

Limiter l’escalade de privilège au programme rsync

Si vous voulez faire une sauvegarde d’éléments un tant soit peu sensible, votre compte aura à faire une escalade de privilège pour que l’OS lui autorise l’accès. On peut prendre pour exemples les dossiers personnels, ou encore les bases de données. Pour ce faire, une bonne technique est de permettre à backup, l’utilisation de sudo. Ce programme implémente un niveau de filtrage intéressant. Il serait bête de ne pas en profiter. 🙂 Je vous invite donc à l’installer sur vos clients et à ajouter cette entrée dans le fichier /etc/sudoers :

backup ALL=NOPASSWD : /usr/bin/rsync

De cette façon, le seul programme que l’utilisateur backup pourra exécuter avec les droits root sera rsync.

Limiter l’utilisation du certificat ssh

Il pourrait être intéressant de rendre le certificat du serveur créé précédemment uniquement fonctionnel depuis celui-ci. Pour ce faire, il va falloir modifier le fichier authorized_keys du compte de backup sur tous les clients, et ajouter la directive from au certificat. Voici le fichier /home/backup/.ssh/authorized_keys original :

backup@spz:/home$ cat /home/backup/.ssh/authorized_keys 
ssh-rsa AAAAB3NzaC1yc2E… nom_du_compte 

Et le voici avec l’attribut ajouté :

backup@spz:/home$ cat /home/backup/.ssh/authorized_keys
from="" ssh-rsa AAAAB3NzaC1yc2E… nom_du_compte

Autres possibilités d’amélioration

Il reste cependant d’autres points qui pourraient être sécurisés.

  • Il serait intéressant de limiter l’utilisateur backup à un compte en read-only, tant qu’on n’a pas besoin de faire de restauration. Ça devrait être gérable pour peu que notre noyau ait grsec ou selinux d’activé, mais je n’ai pas encore approfondi la question.
  • Mettre en place un fail2ban sur le formulaire d’authentification à l’interface Web pour éviter d’être brute-forcé.
  • Configurez iptables pour ne permettre d’établir une connexion uniquement que sur les adresses IP des clients. Une exception pourra être faite pour le port 80 si vous désirez avoir accès à l’interface Web depuis l’extérieur. Dans ce cas, il faudra penser à la protection anti-brute-force avec fail2ban. Attention également aux IP dynamiques : la mise à jour devra être faite manuellement. En effet, le changement de valeur d’un nom de domaine ne permet pas automatiquement à iptables de se mettre à jour.
  • Mettre en place un script d’alerte sur l’état du disque dur. Le mien ne gère malheureusement pas S.M.A.R.T., je vais voir s’il existe un autre moyen de diagnostic.
  • Comme un Raspeberry Pi n’est pas la chose la plus fiable en tant que serveur, il serait aussi certainement intéressant de concevoir à l’utilisation d’un système de monitoring, comme Shinken pour être tenu au courant du moindre problème. Évidemment, cette solution est un peu over-kill pour notre utilisation… Mais il faudrait au moins un script de ping qui teste automatiquement s’il est toujours encore vivant, ça n’est pas du luxe. Il m’est en effet, déjà arrivé de passer une semaine avec le serveur de planté avant que je ne m’en aperçoive. ^^ »

Je pense que c’en est fini pour ce guide. Je sais qu’à première vue, tout ça peut paraître compliqué. Mais bon, il ne s’agit principalement que de tâches basiques pour un administrateur système. Il faut donc passer outre cette première appréhension et continuer jusqu’au bout. Avoir ses données dans un parc qu’on maitrise, ça n’a de toute façon pas de prix. 🙂

Ceci n'est pas une carte mère. 8-)
Ceci n’est pas une carte mère. 😎
,

2 réponses à “Utiliser un Raspberry Pi comme serveur de backup”

    • Salut Nono. 😉
      Ça peut avoir son utilité si plus tard on souhaite passer sous une autre distribution que Raspbian, sans trop s’emmerder car il suffira de formater la racine.