The Amanda Experience – Part 1
Il n'y a pas si longtemps que ça, je vous présentais les rudiments d'une usine à gaz, le bien nommé TSM, et dadu m'avait fait remarqué que d'autres infrastructures se montreraient plus pertinentes, surtout du côté Open-Source. Et sur ce point, il n'avait pas tort. Donc aujourd'hui, je m'attaque à Amanda, dont les premières sources datent de Mai 2006. Le site officiel se trouve par ici.
Nous allons donc jouer un peu avec Amanda, un système de sauvegarde intelligent, compliant et Open Source qui entre directement en course avec TSM.
What you pay is what you get...
Beaucoup de hautes têtes pensent que l'on a les fonctionnalités que l'on a payées, et que plus on paie cher, et plus on est fiable. Cet avis va souvent à l'encontre de celui qui gère l'infrastructure, surtout s'il a déjà été confronté à la hotline fournisseur. Tout ça pour dire qu'Amanda fait partie de ces projets qui démontrent le vrai potentiel de la Communauté sans pour autant imposer le déboursement de sommes rondelettes....Say what ?
Pour faire simple, Amanda est un système de sauvegarde de vos systèmes et vos données, sur disque, sur DVD, sur bandes et sur tout autres périphérique qu'il vous est possible de déclarer, tout en utilisant des formats largement reconnus et des mécanismes et outils standards. Nous allons voir pourquoi cela fait d'Amanda une concurrente redoutable de TSM.Universelle
Le premier point fort d'Amanda est d'utiliser des outils natifs Linux, disponibles depuis n'importe quel kernel, pour effectuer ses sauvegardes. Cela permet d'une part de pouvoir utiliser rapidement des données restaurées depuis un Linux, mais surtout d'être complètement indépendant de la plateforme Amanda, de sorte que, si un jour vous souhaitez changer de système, vous n'êtes absolument pas tenu par les formats sous lesquelles vos données ont été sauvegardées, et donc vos sauvegardes restent valides. Alors oui, vous avez bien lu la première ligne, celle qui parle de Linux, mais que les Windowsiens se rassurent, Amanda a porté son client pour Windows, pour MacOS X et pour les purs Unix, OpenSolaris compris.Scalable et organisée
Le nerf de la guerre. En effet, quand on choisit une solution, et surtout si elle s'avère être très complète et donc difficilement maîtrisable aux premiers abords, on aimerait bien qu'elle soit pérenne et facilement adaptable aux grandes architectures, parce qu'un parc est destiné à s'accroître. Amanda a été conçue pour honorer ces principes et permet une organisation claire de son infrastructure, de la configuration aux périphériques de stockage.Organisations des acteurs
Plusieurs configurations Amanda peuvent être définies et cohabiter sur un même serveur, on peut ainsi dissocier certaines instances de sauvegardes, les configurer selon des règles et des cycles plus appropriés, auxquelles seront rattachées des unités de stockages communes ou distinctes, et qui peuvent présenter des caractéristiques différentes. Par la suite, on appellera ces différents sets de configuration des profils. Il est également possible de faire tourner plusieurs serveurs de sauvegarde Amanda et d'orienter les clients vers l'un ou vers l'autre, de manière à avoir une organisation de ses données en fonction des caractéristiques du serveur. En soi, cela n'a pas tellement d'avantage, mais si on couple avec un dispositif de load balancing (CARP, par exemple), alors cela peut prendre tout son intérêt. Certains penseront que les mécanismes de load balancing n'ont pas beaucoup de pertinence pour un système de sauvegardes. Cette théorie est vraie tant que vos serveurs critiques tournent correctement. Pensez donc un peu au jour où il y aura un pépin. Mieux vaut se prémunir d'une très longue journée et assurer ses arrières que de se trouver confronté au problème, surtout si ce sont des serveurs de production et d'exploitation. Mais ceci est une autre histoire...Gestion des unités de stockage
Il est également à noter que, puisqu'Amanda utilise des mécanismes de compression et de stockage standards, nous ne sommes pas tenu à un type de stockage, tant que l'on peut définir précisément ses caractéristiques telles que, par exemple, sa vitesse et sa capacité. Cette souplesse permet d'une part de pouvoir se passer d'Amanda lors de l'exploitation des données sauvegardées, et d'autre part d'avoir la capacité de mettre en place des infrastructures de stockage plus évoluées, comme le RAIT (un RAID façon Tape), ou encore le cloud-based storage.Planification et exécution des sauvegardes
Le schedule (comprenez la planification) d'une sauvegarde passe par un cron, lancé depuis le serveur, qui mentionne une périodicité et la commande de sauvegarde spécifique à une configuration. C'est au sein du fichier de configuration du profil que sont définis les cycles de bande, le nombre des bandes disponibles, leur type et le script associé à leur changement. La définition de ces paramètres influent sur la manière dont le serveur Amanda va décider du type des sauvegardes à faire (full, incremental, differential,...).Optimized
La planification de la sauvegarde est automatiquement ajustée selon la charge du serveur. Pour rappel, TSM, lui, se contente de suivre bêtement le planning et le type de sauvegarde imposés par l'administrateur, et si, à cause d'une forte charge du serveur à ce moment, une requête de sauvegarde dépasse la fenêtre de temps liée aux tentatives de contact et de sauvegarde du serveur, alors TSM taggue la sauvegarde de l'hôte en Missed, point final. C'est donc un fabuleux atout qui permet surtout de ne pas avoir à tout réorganiser lors de la mise en place de nouveaux clients à sauvegarder.Gestion des sauvegardes
D'habitude, les politiques de sauvegardes sont spécifiées explicitement par l'administrateur, ce qui implique notamment de dimensionner correctement les espaces de sauvegardes. Avec Amanda, la fonctionnalité existe, néanmoins, Amanda a été conçue pour pouvoir prendre automatiquement ce genre de décision. Le choix du type de backup est alors fait en fonction de plusieurs critères :- la taille estimée des sauvegardes en full et en incrémental
- la date du dernier full backup
- les règles du profil, spécifiées pour chaque partition ou sous-répertoire du système sauvegardé.
Holding disk
Comme beaucoup de systèmes évolués, Amanda utilise un espace de stockage temporaire des données, le holding disk, afin de pouvoir supporter les sauvegardes parallèles et d'éviter tout problème lié à la nature même des tapes (sequential, shoe-shining). Ainsi, si, pour une raison ou pour une autre, la sauvegarde ne peut être écrite sur la tape, Amanda gardera le tout disponible sur cet espace en attendant un rétablissement de la situation. C'est pour cette raison notamment que le holding disk doit supporter au moins 2 fois la plus grosse sauvegarde en terme d'espace consommé.Fonctionnement
Voilà ce qui se passe lors d'une sauvegarde.
Le serveur déclenche les hostilités grâce à notre cron, à une heure précise de la journée. Il examine les éléments en sa possession et décide du type de sauvegarde à appliquer pour le client. Le process de sauvegarde côté serveur va donc se lancer en tant qu'utilisateur désigné dans la configuration à appliquer, et chercher à se connecter au client, avec un type d'authentification, un nom de machine et un port donnés.
Le client, de son côté, va vérifier si la tentative de connexion est légitime (utilisateur, adresse source, port source, authentification, méthode invoquée) en consultant son /var/lib/amanda/.amandahosts. Lorsque tout est conforme, le client autorise la connexion, et les données sont copiées du client sur le serveur, et plus précisément sur le Holding disk. Le serveur a la capacité de supporter plusieurs sauvegardes en parallèle, qui seront toutes stockées sur le même espace temporaire. Une fois les données rapatriées, le serveur commence à pousser les données sur une des unités de stockage, suivant les instructions renseignées dans le /etc/amanda/bux/disklist (où bux est le nom de ma configuration). Ces instructions concernent notamment le type de sauvegarde (dump, tar,...) et ses paramètres, et renvoie sur ceux définis dans le fichier de configuration principal, à savoir /etc/amanda/bux/amanda.conf. Détail intéressant, il y a une unité de stockage par backup. Ce qui implique que si les données à sauvegarder dépassent la taille du média, il faudra explicitement scinder les données et partitions à sauvegarder en ensembles plus petits. C'est un peu ennuyeux, mais l'avantage est très net lors de l'exécution d'un PRA (Plan de Reprise d'Activité), car il n'y a alors pas besoin d'aller chercher et de loader dans le désordre et à répétition plusieurs bandes pour pouvoir restaurer un élément de donné. A la fin de la mise sur bande, Amanda utilise le script de changement d'unité de stockage et place la nouvelle de façon à ce qu'elle soit opérationnelle pour la prochaine exécution. J'en profite pour vous renvoyer sur leur page de How To qui seront plus précis et plus clair que moi. Sur le papier donc, et de par sa conception, c'est donc un excellent système de sauvegarde. Voyons ce que cela donne une fois mis en pratique.Now playing
Puisqu'il existe une documentation se targuant de pouvoir mettre en place Amanda en 15 minutes, je me suis conformée aux étapes qui y sont décrites, et que vous pourrez retrouver ici. Pour information, l'installation a eu lieu sous Mandriva, et vous verrez que ce n'était pas forcément un choix judicieux. Dans un premier temps, nous avons décidé de mettre en place, sur la même machine, le client et le serveur amanda.Tiens ? Ca existe en rpm !
La première étape, bien sûr, est d'installer les composants nécessaires, et, solution de facilité, nous allons faire la douloureuse expérience de les installer via les dépôts disponibles pour notre système. L'installation via les sources sera faites et analysée ultérieurement, car, malgré tout ce qu'on peut en penser, installer depuis un dépôt n'implique pas nécessairement bien installer. OK, let's go !Mise en place et configuration basique
L'interrogation de la base nous renvoie une tripotée de packages.# urpmq -y amanda amanda-client # Client amanda-server # Serveur libamanda-devel # Libraries et documentation concernant le développement d'application reposant sur Amanda libamanda0 # Librairies et documentation libamanda0-client # Librairies pour le client libamanda0-server # Librairies pour le serveur # urpmi amanda-server amanda-clientJusqu'ici, tout se passe correctement. Nous découvrons ce qui a été fait : La construction a les options suivantes :
# amadmin xx version build: VERSION="Amanda-2.5.1" BUILT_DATE="Wed Mar 11 16:53:32 EDT 2009" BUILT_MACH="Linux n1.mandriva.com 2.6.22.18-server-1mdv #1 SMP Mon Feb 11 16:46:24 EST 2008 i686 Intel(R) Xeon(TM) CPU 2.80GHz GNU/Linux" CC="gcc" CONFIGURE_COMMAND="'./configure' 'linux' 'gnu'" paths: bindir="/usr/bin" sbindir="/usr/sbin" libexecdir="/usr/lib/amanda" mandir="/usr/share/man" AMANDA_TMPDIR="/tmp/amanda" AMANDA_DBGDIR="/tmp/amanda" CONFIG_DIR="/etc/amanda" DEV_PREFIX="/dev/" RDEV_PREFIX="/dev/r" DUMP="/sbin/dump" RESTORE="/sbin/restore" VDUMP=UNDEF VRESTORE=UNDEF XFSDUMP="/sbin/xfsdump" XFSRESTORE="/sbin/xfsrestore" VXDUMP=UNDEF VXRESTORE=UNDEF SAMBA_CLIENT="/usr/bin/smbclient" GNUTAR="/bin/tar" COMPRESS_PATH="/bin/gzip" UNCOMPRESS_PATH="/bin/gzip" LPRCMD="/usr/bin/lpr" MAILER="/usr/bin/Mail" listed_incr_dir="/var/lib/amanda/gnutar-lists" defs: DEFAULT_SERVER="localhost" DEFAULT_CONFIG="DailySet1" DEFAULT_TAPE_SERVER="localhost" HAVE_MMAP HAVE_SYSVSHM LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE AMANDA_DEBUG_DAYS=4 BSD_SECURITY RSH_SECURITY USE_AMANDAHOSTS CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc"Nous découvrons également le paramétrage de xinetd, qui aura pour mission de gérer à la demande le démarrage et l'arrêt des process liés à Amanda. Par défaut, les services sont mis à off juste après l'installation.
/etc/xinetd.d/amanda // Client /etc/xinetd.d/amandaidx // Serveur /etc/xinetd.d/amidxtape // Serveur : tapeQuelques exemples sont mis à disposition, qui seront à customiser et qui constituent une bonne base pour se familiariser avec la configuration d'Amanda. Ces fichiers appartiennent à la partie serveur et ne sont donc pas à reporter sur les clients.
# ls -lsaR /etc/amanda /etc/amanda: total 24 4 drwxr-xr-x 3 amanda disk 4096 2010-04-13 11:59 ./ 12 drwxr-xr-x 123 root root 12288 2010-04-13 11:59 ../ 4 -rw-r--r-- 1 amanda disk 500 2009-03-11 21:55 crontab.sample 4 drwxr-xr-x 2 amanda disk 4096 2010-04-13 11:59 DailySet1/ /etc/amanda/DailySet1: total 32 4 drwxr-xr-x 2 amanda disk 4096 2010-04-13 11:59 ./ 4 drwxr-xr-x 3 amanda disk 4096 2010-04-13 11:59 ../ 20 -rw-r--r-- 1 amanda disk 17638 2009-03-11 21:55 amanda.conf 4 -rw-r--r-- 1 amanda disk 2099 2009-03-11 21:55 disklistEt comme on a pu le constater rien qu'en regardant les permissions des fichiers, un utilisateur amanda:disk a été crée.
# id amanda uid=81(amanda) gid=6(disk) groupes=6(disk)La suite n'a rien de bien compliqué et se déroule sans encombre jusqu'au premier accro, au niveau du labelling des vtapes.
/tmp/vtapes/bux/slots # for ((i=1; $i<=5;i++)); do amlabel bux bux-0$i slot $i;done amlabel: could not load slot "slot1": need 'rwx' access to '/usr/adm/amanda' amlabel: could not load slot "slot2": need 'rwx' access to '/usr/adm/amanda' amlabel: could not load slot "slot3": need 'rwx' access to '/usr/adm/amanda' amlabel: could not load slot "slot4": need 'rwx' access to '/usr/adm/amanda' amlabel: could not load slot "slot5": need 'rwx' access to '/usr/adm/amanda'Effectivement, le problème est évident. /usr/adm/amanda n'existe pas. Ce répertoire est en fait destiné à accueillir les états liés aux tapes, plus précisément lors du changement de tape. Il n'est mentionné dans aucun fichier de configuration d'Amanda et n'a pas été crée lors de l'installation, ce qui peut faire penser soit à un défaut lors de la création du rpm, soit à un historique de code qui n'a pas été mis à jour et pris en compte. Quoi qu'il en soit, la création et l'attribution à amanda:disk permet de relabeller normalement les vtapes. Ce labelling est en effet obligatoire car il rentre en jeu lors des restaurations, afin que le serveur puisse garder une trace des tapes sur lesquelles il a fait tel backup de tel machine et qu'il puisse s'adresser directement à la bonne tape.
# mkdir -p /usr/adm/amanda # chown -R amanda:disk /usr/adm/amanda # ls -al /usr/adm/amanda total 20 drwxr-xr-x 2 amanda disk 4096 2010-04-22 10:50 . drwxr-xr-x 3 root root 4096 2010-04-22 10:50 .. -rw------- 1 amanda disk 2 2010-04-23 16:06 changer-status-access -rw------- 1 amanda disk 2 2010-04-23 14:01 changer-status-clean -rw------- 1 amanda disk 2 2010-04-23 16:06 changer-status-slotNous suivons le quick start, sans encombre. Le second souci apparaît vers la fin de la procédure, lors de la vérification .
# amcheck bux Amanda Tape Server Host Check ----------------------------- Holding disk /home/amanda/hldd: 42654872 kB disk space available, that's plenty slot 5: read label `bux-05', date `20100423' NOTE: skipping tape-writable test Tape bux-05 label ok WARNING: tapecycle (5) <= runspercycle (28). NOTE: conf info dir /home/amanda/info/bux/curinfo does not exist NOTE: it will be created on the next run. Server check took 0.083 seconds Amanda Backup Client Hosts Check -------------------------------- WARNING: kamanda : selfcheck request failed: timeout waiting for ACK Client check: 1 host checked in 30.070 seconds, 1 problem found (brought to you by Amanda 2.5.1)Et oui. Notre serveur répond bien, promptement -normal, me direz-vous, il tourne en local-, mais le client, lui, ne réagit pas. L'analyse du log généré nous renvoie un problème de bind.
amcheck-clients: time 68.189: bind_portrange: all ports between 512 and 1023 busy amcheck-clients: dgram_bind: Could to bind to port in range: 512 - 1023. amcheck-clients: time 68.189: dgram_bind: socket bound to 0.0.0.0.33672 security_seterror(handle=0x8657168, driver=0xb77c2ca0 (BSD) error=unable to bind to a reserved port (got port 33672)) security_close(handle=0x8657168, driver=0xb77c2ca0 (BSD)) amcheck: pid 28531 finish time Fri Apr 23 10:42:44 2010La première réaction tient de l'effroi. Mais pourquoi binder sur les reserved ports ? D'autant plus que ce n'est stipulé nulle part. Et bien c'est simple. BSDTCP -enfin BSD- demande un reserved port. Or, l'utilisateur créé pour faire tourner le serveur ne dispose pas des privilèges pour se faire. C'est même pire. Si l'on examine le fichier /etc/services, on peut constater que cela ne suit pas du tout ce qui était prévu.
# grep amanda /etc/services amanda 10080/tcp # amanda backup services amanda 10080/udp # amanda backup services kamanda 10081/tcp # amanda backup services (Kerberos) kamanda 10081/udp # amanda backup services (Kerberos) amandaidx 10082/tcp # amanda backup services amidxtape 10083/tcp # amanda backup servicesCette contrainte sur les ports réservés nous oblige à faire ce que l'on n'aime pas faire : faire tourner le serveur Amanda en tant que root. Cette modification d'utilisateur est à opérer sur plusieurs configurations : - /etc/xinetd.d/amandaserver :
user = root group = root- /etc/amanda/bux/amanda.conf :
user = root group = root- /var/lib/amanda/.amandahosts
amanda root amdump amindexd amidxtaped localhost.localdomain root amdump amindexd amidxtapedLe résultat n'est guère mieux, mais on avance, comme le mentionne le log :
amcheck-clients: time 0.039: bind_portrange2: Try port 768: Available - Success
amcheck-clients: time 0.040: dgram_bind: socket bound to 0.0.0.0.768
amcheck-clients: dgram_send_addr(addr=0xbfe4747c, dgram=0xb76e5c44) changer_query: changer return was 5 1 changer_query: searchable = 0 changer_find: looking for bux-05 changer is searchable = 0
amcheck-clients: dgram_send_addr(addr=0xbfe4739c, dgram=0xb76e5c44)
amcheck-clients: (sockaddr_in *)0xbfe4739c = { 2, 24615, *.*.*.* }
amcheck-clients: dgram_send_addr: 0xb76e5c44->socket = 4
amcheck-clients: dgram_send_addr(addr=0xbfe4739c, dgram=0xb76e5c44)
amcheck-clients: (sockaddr_in *)0xbfe4739c = { 2, 24615, *.*.*.* }
amcheck-clients: dgram_send_addr: 0xb76e5c44->socket = 4
security_seterror(handle=0x8e84748, driver=0xb76e4ca0 (BSD) error=timeout waiting for ACK)
security_close(handle=0x8e84748, driver=0xb76e4ca0 (BSD)
Après nous avoir informé que l'erreur avait de grandes chances de se trouver sur la configuration client, la documentation nous suggère alors de tester le lancement du daemon amandad avec ses attributs sous l'utilisateur mentionné.
Lançons le client :
# /usr/lib/amanda/amandad -auth=bsdtcp amdumpAu lieu de timeouter 30 secondes plus tard, la commande termine immédiatement, avec un log qui n'a écrit que la configuration actuelle de amandad. Un strace nous renseigne sur le souci :
getpeername(0, 0xbfc6cb08, [16]) = -1 ENOTSOCK (Socket operation on non-socket)Par curiosité, et conformément à la documentation, nous avons modifié le protocol d'authentification de bsdtcp à local. Nous nous faisons jeter par le security driver qui nous dit que local n'est pas reconnu comme protocol :
amandad: no driver for security type 'local'Même manip, mais en remplaçant bsdtcp par bsd, la commande fait enfin le timeout normal de 30 seconds. Mais le amcheck est toujours infructueux. Nous décidons de remplacer stream (qui est propre à tcp) par dgram (propre à udp) et donc d'aligner sur udp. Timeout normal. Amcheck ok. Résultat :
# amcheck bux Amanda Tape Server Host Check ----------------------------- Holding disk /home/amanda/hldd: 42653204 kB disk space available, that's plenty slot 4: read label `bux-04', date `20100423' NOTE: skipping tape-writable test Tape bux-04 label ok WARNING: tapecycle (5) <= runspercycle (28). NOTE: conf info dir /home/amanda/info/bux/curinfo does not exist NOTE: it will be created on the next run. Server check took 0.091 seconds Amanda Backup Client Hosts Check -------------------------------- Client check: 1 host checked in 0.064 seconds, 0 problems found (brought to you by Amanda 2.5.1) # amadmin bux find Scanning /home/amanda/hldd... date host disk lv tape or file file part status 2010-04-29 amanda /home/amanda/process/git 0 bux-04 1 -- OKPar contre, il est intéressant de remarquer que 2 amcheck successifs donnent des résultats différents, un ok et un failed. Il faut donc constamment redémarrer xinetd à la main pour que les 2 soient ok. Cette manipulation peut amener beaucoup de problèmes dans le cas justement de sauvegardes automatisées.
# amcheck bux Amanda Tape Server Host Check ----------------------------- Holding disk /home/amanda/hldd: 42653172 kB disk space available, that's plenty slot 5: read label `bux-05', date `20100428' NOTE: skipping tape-writable test Tape bux-05 label ok WARNING: tapecycle (5) <= runspercycle (28). Server check took 0.119 seconds Amanda Backup Client Hosts Check -------------------------------- Client check: 1 host checked in 0.072 seconds, 0 problems found (brought to you by Amanda 2.5.1) # amcheck bux Amanda Tape Server Host Check ----------------------------- Holding disk /home/amanda/hldd: 42653172 kB disk space available, that's plenty slot 5: read label `bux-05', date `20100428' NOTE: skipping tape-writable test Tape bux-05 label ok WARNING: tapecycle (5) <= runspercycle (28). Server check took 0.085 seconds Amanda Backup Client Hosts Check -------------------------------- WARNING: amanda: selfcheck request failed: timeout waiting for ACK Client check: 1 host checked in 30.067 seconds, 1 problem found (brought to you by Amanda 2.5.1)Passons à la partie accès aux données sauvegardées / restauration.
Accès aux données sauvegardées et restauration
L'arborescence originale à sauvegarder est telle que :# ls -lsa /home/amanda/process/git total 48952 4 drwxr-xr-x 3 root root 4096 2010-04-29 10:51 ./ 4 drwxr-xr-x 11 amanda disk 4096 2010-04-16 14:36 ../ 4 -rw-r--r-- 1 root root 97 2010-03-22 14:19 bux_org 48936 -rw-r--r-- 1 root root 50054323 2010-04-29 10:51 eclipse-cpp-galileo-SR2-linux-gtk-x86_64.tar.gz 4 drwxr-xr-x 8 root root 4096 2010-03-22 14:19 .git/La sauvegarde fonctionne correctement, du moins, c'est ce que nous affirme le rapport :
These dumps were to tape bux-01. The next tape Amanda expects to use is: bux-02. STATISTICS: Total Full Incr. -------- -------- -------- Estimate Time (hrs:min) 0:00 Run Time (hrs:min) 0:00 Dump Time (hrs:min) 0:00 0:00 0:00 Output Size (meg) 47.8 47.8 0.0 Original Size (meg) 47.9 47.9 0.0 Avg Compressed Size (%) 99.8 99.8 -- Filesystems Dumped 1 1 0 Avg Dump Rate (k/s) 9455.8 9455.8 -- Tape Time (hrs:min) 0:00 0:00 0:00 Tape Size (meg) 47.8 47.8 0.0 Tape Used (%) 0.0 0.0 0.0 Filesystems Taped 1 1 0 Chunks Taped 0 0 0 Avg Tp Write Rate (k/s) #####.# #####.# -- USAGE BY TAPE: Label Time Size % Nb Nc bux-01 0:00 48928k 0.0 1 0Première difficulté, arriver à lancer amrecover.
# amrecover bux AMRECOVER Version 2.5.1. Contacting server on localhost ... 220 AMANDA index server (2.5.1) ready. Setting restore date to today (2010-04-29) 200 Working date set to 2010-04-29. 501 Could not read tapelist file /home/amanda/info/bux/tapelist! amrecover> quit 200 Good bye. # ll /home/amanda/info/bux/tapelist -rw------- 1 root root 108 2010-04-29 10:09 /home/amanda/info/bux/tapelist # chmod 755 /home/amanda/info/bux/tapelist # amrecover bux AMRECOVER Version 2.5.1. Contacting server on localhost ... 220 AMANDA index server (2.5.1) ready. Setting restore date to today (2010-04-29) 200 Working date set to 2010-04-29. Warning: no log files found for tape bux-05 written 2010-04-29 Warning: no log files found for tape bux-04 written 2010-04-29 Warning: no log files found for tape bux-03 written 2010-04-29 Warning: no log files found for tape bux-02 written 2010-04-28 Warning: no log files found for tape bux-01 written 2010-04-28 Scanning /home/amanda/hldd... 200 Config set to bux. 200 Dump host set to amanda Use the setdisk command to choose dump disk to recover amrecover> listdisk 200- List of disk for host amanda 201- /home/amanda/process/git 200 List of disk for host amanda amrecover> setdisk /home/amanda/process/git 200 Disk set to /home/amanda/process/git. No index records for disk for specified date If date correct, notify system administrator amrecover> lsPremière remarque, si l'on souhaite remonter dans le temps, il suffit de jouer avec l'instruction setdate depuis amrecover. Mais plus important et plus affolant... Il n'y a rien ! D'après amrecover, aucune donnée n'est visible. Pourtant, un simple ls -lsa sur l'unité de stockage utilisée nous montre qu'il existe des fichiers dont les tailles coïncident avec celles des entités présentes sur l'arborescence d'origine.
# ls -lsa /tmp/vtapes/bux/slots/slot1/ total 49064 4 drwxr-xr-x 2 root root 4096 2010-04-29 11:17 ./ 4 drwxr-xr-x 7 root root 4096 2010-04-29 11:17 ../ 4 -rw------- 1 root root 10 2010-04-29 11:17 00000-bux-01 32 -rw------- 1 root root 32768 2010-04-29 11:17 00000.bux-01 4 -rw------- 1 root root 13 2010-04-29 11:17 00001-amanda._home_amanda_process_git.0 48980 -rw------- 1 root root 50102272 2010-04-29 11:17 00001.amanda._home_amanda_process_git.0 4 -rw------- 1 root root 10 2010-04-29 11:17 00002-TAPEEND 32 -rw------- 1 root root 32768 2010-04-29 11:17 00002.TAPEENDEn fait, si l'on regarde bien, Amanda nous a signalé où se trouvait le souci : "No index records for disk for specified date". Ces index records (littéralement, enregistrement d'index) sont essentiels lorsque l'on veut manipuler les données avec amrecover, mais cela ne veut pas dire que tout n'est pas récupérable. Souvenez-vous, on a dit universel. Ainsi, pour récupérer les données dans ce cas de figure, c'est-à-dire sans avoir défini d'index, il faut préférer passer par la commande amrestore. Le résultat de cette commande est la création d'un fichier dans le répertoire courant, de type tar.
# amrestore /tmp/vtapes/bux/slots/slot1/00001.amanda._home_amanda_process_git.0 amrestore: 0: restoring amanda._home_amanda_process_git.20100429.0 # ll /tmp/vtapes/bux/slots total 49412 lrwxrwxrwx 1 root root 27 2010-04-29 14:28 data -> /tmp/vtapes/bux/slots/slot1/ -rw------- 1 root root 15 2010-04-29 14:28 info -rw-r----- 1 root root 50513920 2010-04-29 14:56 amanda._home_amanda_process_git.20100429.0 [...] # file /tmp/vtapes/bux/slots/amanda._home_amanda_process_git.20100429.0 amanda._home_amanda_process_git.20100429.0: POSIX tar archive (GNU)A partir de cela, il ne nous reste plus qu'à renomme amanda._home_amanda_process_git.20100429.0 en amanda._home_amanda_process_git.20100429.0.tar et à détarer l'archive. Il est facile de s'apercevoir de la limitation de amrestore par rapport à amrecover. En effet, amrestore impose qu'on lui indique directement l'emplacement du périphérique de stockage sur lequel se trouvent les données à restaurer. Or, même si les rapports de sauvegardes stipulent clairement sur quelle unité de stockage les sauvegardes ont été faites, et même si Amanda n'utilise qu'une tape par backup, cela devient vite ingérable dans le cas où nous disposons de longues périodes de rétention de données et de beaucoup de tape. Amrecover, lui, utilise intelligemment la puissance d'Amanda et s'appuie sur les labels pour rechercher et se positionner automatiquement sur les données à restaurer selon la date précisée. Par conséquent, plutôt que de fonctionner tel quel, c'est à dire sans index, nous allons donc les mettre en place afin de pouvoir, nous aussi, bénéficier de cet atout majeur. Pour cela, il suffit de rajouter à notre méthode de dump -ou, plus rapidement, à la section dumptype global- les 2 éléments : record yes et index yes. Et ne pas oublier de relancer xinetd.
Epilogue
Catastrophe. L'installation et le paramétrage du serveur via les rpms suit un chemin tellement différent de celui donné par le Quick Start qu'il en reviendrait presque à décevoir. On regrettera des fonctionnalités annoncées et testées, mais qui ne fonctionnent pas sur notre serveur, comme l'authentification BSDTCP, les inadéquations, les imprécisions ou encore l'utilisation de services à la demande, comme xinetd, qui n'ont pas su correctement répondre à certaines requêtes malgré que les précédentes (de quelques secondes) aient réussi. Petite remarque sur la documentation du projet également, puisque certaines parties sont obsolètes alors que d'autres renvoient à un troubleshooting via la version supérieure, dernière en date. Malgré tout, je pense que ce manque de rigueur n'est pas à imputer directement à la Communauté, puisque les tests sont partis sur une installation depuis les dépôts de Mandriva, et donc précompilée avec certaines options qui ne sont certes pas les plus appropriées. Ainsi, la mise en place du serveur Amanda depuis les rpm de Mandriva est donc loin, très loin de tourner autour des 15 minutes (quoique, une fois les problèmes cernés, on doit y arriver). En revanche, on ne peut pas nier que celle des clients est plus simple et surtout facilement automatisable. Du fait qu'Amanda s'occupe de gérer tout seul tout ce qui touche aux backups et aux schedules, on a vite fait le compte. En conséquence, à la longue, il est donc nettement plus intéressant d'utiliser Amanda que de se rabattre sur TSM, car, même si l'on pourrait prêcher garantie de fonctionnement et grand nom, il est clair que TSM demande autant sinon plus de formation avant d'avoir une configuration opérationnelle, et attend quotidiennement une attention particulière, d'autant plus accrue lors de l'expansion de clients, sans pour autant optimiser tout ce qui touche aux PRA et aux schedulings. De son côté, Amanda est capable de mettre en place tous les moyens à sa disposition pour faciliter, uniformiser, standardiser et gérer au mieux les sauvegardes, les restaurations et l'évolution des infrastructures, sans pour autant lier l'utilisateur à la technologie. Enfin, pour tous ceux qui ont pris peur, n'ayez crainte. D'une part, il reste à tester l'installation et la configuration depuis des sources propres du projet et d'autre part, Amanda n'est pas le seul OpenSource backup management system dans la course... A suivre, donc ! Annexe des fichiers en l'état :/etc/amanda/bux/
# /etc/amanda/bux/amanda.conf.
org "bux" # your organization name for reports
mailto "amanda@amanda" # space separated list of operators at your site
dumpuser "root"
dumpcycle 4 weeks # the number of days in the normal dump cycle
runspercycle 4 weeks # the number of amdump runs in dumpcycle days
tapecycle 5 tapes # the number of tapes in rotation
bumpsize 20 Mb # minimum savings (threshold) to bump level 1 -> 2
bumpdays 1 # minimum days at each level
bumpmult 4 # threshold = bumpsize * bumpmult^(level-1)
etimeout 300 # number of seconds per filesystem for estimates.
runtapes 1 # number of tapes to be used in a single run of amdump
tpchanger "chg-disk"
tapedev "file:/tmp/vtapes/bux/slots"
tapetype HD # what kind of tape it is (see tapetypes below)
labelstr "bux.*" # label constraint regex: all tapes must match
holdingdisk hd1 {
comment "main holding disk"
directory "/home/amanda/hldd" # where the holding disk is
use 290 Mb # how much space can we use on it
}
infofile "/home/amanda/info/bux/curinfo" # database filename
logdir "/home/amanda/info/bux" # log directory
indexdir "/home/amanda/info/bux/index" # index directory
tapelist "/home/amanda/info/bux/tapelist" # list of used tapes
define tapetype HD {
comment "Disk"
length 100000 mbytes
}
define dumptype global {
comment "Global definitions"
auth "bsd"
dumpcycle 0
record yes
index yes
}
define dumptype always-full {
global
comment "Full dump of this filesystem always"
compress none
priority high
dumpcycle 0
}
define dumptype comp-utar {
global
program "GNUTAR"
compress fast
}
define dumptype holding-disk {
global
comment "The master-host holding disk itself"
holdingdisk no # do not use the holding disk
priority medium
}
define interface local {
comment "a local disk"
use 1000 kbps
}
define interface eth0 {
comment "10 Mbps ethernet"
use 400 kbps
# EOF /etc/amanda/bux/amanda.conf
disklist
#/etc/amanda/bux/disklist amanda /home/amanda/process/git comp-utartapelist /var/lib/amanda/ .amandahosts
amanda root amdump amindexd amidxtaped localhost.localdomain root amdump amindexd amidxtaped/etc/xinetd.d/ amandaserver
# default: off
# description: The client for the Amanda backup system.\
# This must be on for systems being backed up\
# by Amanda.
service amanda
{
socket_type = dgram
protocol = udp
wait = no
user = root
group = root
groups = yes
server = /usr/lib/amanda/amandad
server_args = -auth=bsd amdump amindexd amidxtaped
disable = no
}
amandaclient
# default: on
# #
# # description: Amanda services for Amanda client.
# #
service amandaclient
{
disable = no
socket_type = dgram
protocol = udp
wait = no
user = root
group = root
groups = yes
server = /usr/lib/amanda/amandad
server_args = -auth=bsd amdump
}
amandaidx
# default: off
#
# description: Part of the Amanda server package
service amandaidx
{
socket_type = dgram
protocol = udp
wait = no
user = root
group = root
groups = yes
server = /usr/lib/amanda/amindexd
disable = no
server_args = -auth=bsd amdump amindexd amidxtaped
}
amidxtape
# default: off
#
# description: Part of the amanda server package
#
service amidxtape
{
socket_type = dgram
protocol = udp
wait = no
user = amanda
group = disk
groups = yes
server = /usr/lib/amanda/amidxtaped
server_args = -auth=bsdtcp -tcp=10083 amcheck amdump amindexd amidxtaped
disable = no
}
tags :
