The Amanda Experience – Part 1

30/04/10

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é.

Il est également possible de définir, jusqu’au niveau fichier, une politique d’encryption, d’exclusion, de compression et de stockage.

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.