Ecole Ingénieurs 2000 - Université de Marne-la-Vallée Filière Informatique et Réseaux 1 ère année Administration Système ****** Compte Rendu projet n 4 ****** Le but de ce projet est de prévoir un système de sauvegarde de données Compte rendu de : Tom MIETTE Sébastien MOURET Fait le : 1er avril 2007
Sommaire SOMMAIRE...2 INTRODUCTION...3 I. POURQUOI UNE SAUVEGARDE EN RESEAU...4 1. Nécessité d une sauvegarde...4 2. L évolution de l organisation des ordinateurs...4 3. L utilisateur de la machine...4 4. Le type de sauvegarde...4 5. Introduction à la sauvegarde incrémentale (Dump)...5 II. CHOIX DU MATERIEL...6 1. Côté serveur...6 1.1 Le processeur... 6 1.2 La mémoire... 6 1.3 Les disques... 7 2. Côté bandes...8 2.1 Les bandes magnétiques... 8 2.2 Le lecteur de bandes... 10 III. CHOIX DU LOGICIEL...11 1. Présentation...11 1.1 Les impératifs pour ce genre de logiciels... 11 1.2 Les différentes solutions... 11 2. Pourquoi Amanda?...13 2.1 Présentation... 13 2.2 Les points forts d'amanda... 13 2.3 Stratégie maître-esclave... 14 3. Le mécanisme...15 3.1 Sur le serveur... 15 3.2 Sur les clients.... 15 3.3 L'ordonnancement... 15 3.4 Planification automatique des tâches... 16 3.5 Compression des données... 17 3.6 Formats de sauvegarde... 17 3.7 Changeur de bandes... 18 3.8 Configuration... 18 IV. INSTALLATION ET CONFIGURATION DU LOGICIEL...19 1. Configuration d'une sauvegarde : le serveur...19 2. Configuration d'une sauvegarde : les clients...23 3. La première sauvegarde et restauration...23 4. Paramétrage de la sauvegarde hebdomadaire...26 V. BUDGET...27 CONCLUSION...28 BIBLIOGRAPHIE...29 ANNEXES...30 Tom MIETTE Sébastien MOURET 2 / 31
Introduction Le but de ce projet est de prévoir un système de sauvegarde de données. Le volume de données est de 500 Go. Le nombre de fichier est de l ordre de 10000. Le serveur est dédié à la sauvegarde. Le site travaille au niveau national. Une sauvegarde sur bande est nécessaire pour externalisation. Une restitution doit prendre moins d une demi-journée. Les bases de données sont sauvegardées à froid. Vous expliciterez la stratégie de sauvegarde, la politique ainsi que les procédures mises en place pour la sauvegarde et la restitution. Dans ce rapport, nous essayerons donc de mettre en place un système de sauvegarde pour une entreprise d envergure nationale. Notre objectif est à la fois de choisir une solution hardware mais aussi une solution logicielle pouvant satisfaire un tel système. La quantité de données à sauvegarder, la taille de l entreprise concernée et le type de sauvegarde des bases de données sont autant de paramètre qui aiguilleront notre réflexion afin de trouver le moyen le plus adapté à cette situation. Il est a noté que tout notre travail reste dans un cadre assez générique pouvant s adapter à plusieurs entreprises de tailles différentes car nous ne voulions pas répondre à une situation particulière. Pour répondre à l énoncé, nous présenterons notre solution en cinq temps. Dans une première partie, nous justifierons notre choix d une sauvegarde en réseau. Nous présenterons ensuite les choix matériel et logiciel dans les deuxième et troisième parties. Puis dans une quatrième partie, nous préciserons la procédure d installation de configuration du logiciel que nous avons choisi. Et enfin, nous conclurons ce rapport avec un court paragraphe sur le budget que nous avons estimé pour la mise en place de ce système de sauvegarde. Tom MIETTE Sébastien MOURET 3 / 31
I. Pourquoi une sauvegarde en réseau 1. Nécessité d une sauvegarde Attaques virales, crash de disque dur, incendie, corruption de fichiers, vol de matériel... La liste des raisons poussant les décideurs IT 1 à sauvegarder leurs fichiers en ligne, auprès de prestataires ASP 2, est longue. D'autant que les volumes de données augmentent constamment, tandis que les liaisons ADSL offrent des débits de plus en plus élevés à des coûts toujours plus bas. 2. L évolution de l organisation des ordinateurs En quelques dizaines d'années seulement l'informatique a subi beaucoup de bouleversements. Nous sommes passés d'une architecture de «mainframe 3» à une architecture «distribuée 4». Un des résultats de cette évolution est que les «données» à sauvegarder se sont trouvées disséminées sur une multitude de postes multipliant ainsi le nombre de postes à sauvegarder. 3. L utilisateur de la machine Une réponse a cette dissémination des données a été dans un premier temps de demander á chaque utilisateur de faire lui même ses sauvegardes des données «importantes». Ainsi non seulement il faut multiplier les périphériques de sauvegarde mais de plus l'utilisateur doit s'astreindre á une discipline très rigoureuse. Dans les faits ces sauvegardes ne sont jamais faites régulièrement car il y a toujours quelque chose de plus important à faire. Le recours à des personnes dédiées à cette tâche devient obligatoire. La sauvegarde en réseau permet d'avoir une personne qui effectue les sauvegardes pour tous les utilisateurs. 4. Le type de sauvegarde La quantité de données qu'on peut stocker sur une bande a beaucoup évolué ces dernières années. Ainsi on est passé typiquement de bandes de 150 Mo à des bandes de 500 Go ou plus. Néanmoins si on sauvegarde un certain nombre de machines on constate que tout ne peut pas tenir sur une seule bande. De plus une journée ne suffit pas à sauvegarder toutes les machines. Pour pallier à ces difficultés on va utiliser le fait que les données varient en fait très peu sur les machines informatiques. Ainsi à la première sauvegarde on sauvegarde la totalité des données (on l'appelle le niveau 0) et à la sauvegarde suivante on ne sauvegarde 1 Information Technology société dans lequel les nouvelles technologies jouent un rôle prépondérant. 2 Application Service Provider, sociétés de services informatiques qui fournissent des solutions logicielles à travers un réseau informatique généralement au travers d Internet. 3 Mainframe une architecture mainframe est un système basé sur une entité centrale. Par exemple dans un réseau de type mainframe, un seul serveur traite les informations de tous les ordinateurs du réseau, ainsi quand celui tombe en panne c est le réseau entier qui est paralysé. 4 Voir le schéma en annexe page 32 Tom MIETTE Sébastien MOURET 4 / 31
que les modifications par rapport à ce niveau 0 (le niveau 1) et ainsi de suite. Cela permet donc de réduire le volume des données sauvegardées. Ce type de sauvegarde est communément appelée «sauvegarde incrémentale». 5. Introduction à la sauvegarde incrémentale (Dump 1 ) La sauvegarde incrémentale est un moyen très efficace et sûr de sauvegarder vos données. Ses principaux avantages sont la rapidité et la flexibilité, en ce qui concerne le paramétrage : tout dépendra de la quantité de données que vous voulez sauvegarder, vous pourrez choisir un niveau de sauvegarde qui permettra de réduire le temps nécessaire à la restauration des données (particulièrement lorsque vous avez une grande quantité de données à sauvegarder). La sauvegarde incrémentale est similaire dans sa fonction à l'outil dump, populaire sous Unix, et elle permet de créer une première sauvegarde complète d'un dossier source et ensuite d'y ajouter les fichiers qui ont changés depuis la dernière session de sauvegarde. Une session de sauvegarde dans ce mode est appelée «dump». A chaque sauvegarde (dump) est assigné son propre numéro (un entier de 0 à 9); c'est un niveau de sauvegarde qui détermine quels fichiers seront copiés. Un schéma vaut mieux qu un long discours : 0 3 2 5 4 7 6 9 8 9 0 signifie : sauvegarde complète. 3 signifie : copier tous les fichiers créés ou modifiés depuis les niveaux 0 et 3. 2 signifie : copier tous les fichiers créés ou modifiés depuis les niveaux 0 et 2. 5 signifie : copier tous les fichiers créés ou modifiés depuis les niveaux 0, 3 et 5. 4 signifie : copier tous les fichiers créés ou modifiés depuis les niveaux 0, 3 et 4. 7 signifie : copier tous les fichiers créés ou modifiés depuis les niveaux 0, 3, 4 et 7. 6 signifie : copier tous les fichiers créés ou modifiés depuis les niveaux 0, 3, 4 et 6. 9 signifie : copier tous les fichiers créés ou modifiés depuis les niveaux 0, 3, 4, 6 et 9. 8 signifie : copier tous les fichiers créés ou modifiés depuis les niveaux 0, 3, 4, 6 et 8. 9 signifie : copier tous les fichiers créés ou modifiés depuis les niveaux 0, 3, 4, 6, 8 et 9. 1 Dump commande Unix permettant de sauvegarder un dossier. Elle ne sauvegarde que ce qui a changé entre la période précédente et la période courante. Voir le manuel d Unix pour plus d informations sur son utilisation. Tom MIETTE Sébastien MOURET 5 / 31
II. Choix du matériel 1. Côté serveur Pour mettre en place notre système de sauvegarde, nous devons disposer d un serveur dédié à la sauvegarde. En effet, il est indispensable de disposer d une machine effectuant uniquement les opérations de sauvegarde afin de pérenniser son activité dans le temps et d assurer son bon fonctionnement (non altération des données et non ralentissement des transferts par d autre processus actifs sur la machine, par exemple). Les prochains paragraphes décriront brièvement la configuration que nous avons choisie pour ce serveur de sauvegarde. 1.1 Le processeur Le processeur ne sera pas ici l élément essentiel de notre architecture étant donné les cadences qu offrent aujourd hui les différents modèles. Le choix est donc simple et ne tient pas compte des marques présentes sur le marché. Pour notre système de sauvegarde, nous avons choisi un processeur double cœur cadencé à 4 GHz (environ 2 fois 2.0 GHz) et avec un mémoire cache de 2 Mo maximum. Ce composant permettra de supporter aisément le rapatriement des données et leur écriture sur les différents disques. A titre d exemple, nous pouvons citer le processeur AMD Opteron 875 Dual Core. Budget estimé pour le processeur : de 1.000 à 3.000 euros selon le modèle et la marque. 1.2 La mémoire Quant à la mémoire vive du serveur, il est important qu elle soit performante et en quantité suffisante pour supporter le mécanisme de sauvegarde. C est en effet la RAM (Random Access Memory) qui permet au processeur d avoir un accès rapide aux données et de pouvoir ainsi les traiter dans un temps raisonnable. L objectif ici est donc de donner au processeur une quantité suffisante de mémoire afin qu il effectue le moins d accès disques possibles. Dans notre cas, nous avons choisi d utiliser une quantité de mémoire de 4 Go de type DDR2 (Double Data Rate Two). Tom MIETTE Sébastien MOURET 6 / 31
Cette quantité semble convenir à nos besoins de transferts et de traitements de données. Budget estimé pour la mémoire vive : environ 400 euros. 1.3 Les disques Les disques durs seront les composants du serveur les plus sollicités car c est eux qui chaque jour stockeront les données sauvegardées. Les écritures et lectures régulières sur ces disques ne doivent pas altérer ces précieuses données. De plus, l accès à ces disques doit être le plus rapide possible afin d assurer un taux de transfert toujours optimale. Il ne faut pas oublier que la restitution des données sur les différents serveurs ne doit pas prendre plus d une demi-journée. Enfin, il nous semble indispensable que les données soient stockées de façon redondante sur plusieurs disques afin d assurer une certaine sécurité. C est pourquoi le choix des disques durs est important. Le choix que nous avons fait est de monter en RAID 1 deux disques durs d une capacité d 1 000 Go interfacés en Firewire 2 (ou Firewire Gigabit) avec la machine serveur. Le volume des données à sauvegarder étant estimé à 500 gigaoctets, une capacité d un téraoctet nous permet d une part d avoir un espace disponible suffisant et d autre part de faire face à un possible débordement de capacité (> 500 Go). Schéma de montage des disques en RAID 1 Tom MIETTE Sébastien MOURET 7 / 31
Le RAID 1 permet de faire de disposer de plusieurs disques chacun étant des copies. Sur n disques, les données sont ainsi stockées n fois. Avec ce système sur deux disques, nous prévenons ainsi une éventuelle panne de l un des disques qui pourra être remplacé rapidement sans aucune perte de donnée. Enfin, l interface Firewire Gigabit met à notre disposition un taux de transfert très élevé. En effet, cette norme, aussi appelée IEE 1394b-s3200, offre un débit théorique de 3200 Mbits par seconde. Ce débit nous permet, en théorie, d effectuer le transfert d une masse de donnée de 500 Go en environ 2 minutes et 40 secondes. Cet ordre de grandeur met bien en évidence le fait qu une telle interface de connexion entre les disques et le serveur est suffisante dans notre cas. Il ne faut pas occulter le fait que ce résultat est théorique et que le taux de transfert ne dépend pas uniquement de cette interface. Budget estimé pour les disques : 2500 euros pour les disques et 200 euros pour l interfaçage. 2. Côté bandes Comme le demande l énoncé, dans la mise en place de notre système de sauvegarde, il faut effectuer une externalisation des données sur bandes. En effet, une sauvegarde ne peut être considérée comme fiable si toutes les données sont gardées dans un même lieu physique sans aucune autre copie externe. Un simple incident (incendie, inondation, vol, etc.) peut mettre en péril absolument l intégralité des données stockées et donc potentiellement la vie de l entreprise. C est pour éviter ce genre de problèmes que l externalisation est nécessaire. 2.1 Les bandes magnétiques L utilisation de bandes magnétiques pour ce type de sauvegarde est, nous semble t il, la plus appropriée. Les bandes permettent d une part de stocker une quantité d information extrêmement élevée et d autre part de «déplacer» sans risques les données d un point à un autre. Cependant, ce matériel est le plus lent dans le processus de sauvegarde car pour assurer une copie fiable des données, le taux de transfert vers ce type de périphériques est assez lent comparé aux autres taux. C est donc les bandes magnétiques qui limiteront le temps de restauration censé être inférieur à une demi-journée. Un rapide calcul peut nous montrer le taux de transfert en dessous duquel, nous ne pourrions pas tenir nos objectifs de temps pour une restauration : - Une demi-journée de travail est équivalente à environ 4 heures (H). - La quantité théorique de données à restaurer au maximum est de 500 Go (D). Tom MIETTE Sébastien MOURET 8 / 31
- Nous cherchons le taux de transfert (T). D / T = H ; 500 Go / T = 14 400 secondes ; T = 500 Go / 14 400 s ; T = 0,0347 Go / s; Le taux de transfert minimum acceptable est donc de 0,035 Go par seconde soit 35 Mo par seconde. Ce résultat étant calculé pour une demi-journée exactement, il est préférable de choisir un taux de transfert légèrement supérieur pour assurer une marge de manœuvre. Le choix des bandes magnétiques que nous avons fait repose donc essentiellement sur ce résultat. Ces dernières doivent offrir un débit de transfert supérieur à 35 Mo par seconde. C est pourquoi nous nous sommes tournés vers les bandes magnétiques utilisant la technologie de stockage LTO-Ultrium (Linear Tape Open). Pour information, les différentes générations de bandes magnétiques LTO sont les suivantes : Génération Capacité (en Go) Débit (en Mo / s) LTO-1 100 20 LTO-2 200 40 LTO-3 400 80 LTO-4 800 160 Pour toutes ces générations, la durée de vie de la bande est estimée à environ 30 ans et 20 000 lectures et écritures. En croisant nos besoins en débit et en capacité, nous optons ici pour des bandes magnétiques de 4 ème génération. Avec une capacité de 800 Go et un taux de transfert de 160 Mo par seconde en natif, elles correspondent à notre situation. Ce média nous permettrait de transférer nos données de 500 Go en 52 minutes. Ce résultat reste lui aussi purement théorique surtout en tenant compte du fait que ce délai ne dépend pas seulement des bandes magnétiques. Budget estimé pour les bandes magnétiques : 100 euros l unité. Tom MIETTE Sébastien MOURET 9 / 31
2.2 Le lecteur de bandes Une fois nos bandes magnétiques choisies, il nous faut à présent un lecteur / graveur de bandes approprié pour effectuer nos processus de sauvegardes. Nous avons choisi pour cela un lecteur de bandes de type LTO Quantum compatible avec la technologie Ultrium 4 ème génération. Un tel périphérique possède généralement une interface du type SCSI assurant un débit confortable (entre 68 Mo et 90 Mo par seconde). Il est a noté que les données que nous sauvegarderons sur ces périphériques ne seront pas compressées. Ceci s explique pour deux raisons : d une part, le fait de ne pas compresser les données garantit qu il n y ai pas d éventuelle perte d informations pendant le processus de compression et, d autre part, les bandes offrent un espace de stockage largement suffisant pour enregistrer nos 500 Go de données. Budget estimé pour le lecteur de bandes: 3000 euros. Tom MIETTE Sébastien MOURET 10 / 31
III. Choix du logiciel Il existe énormément de logiciels destinés à la sauvegarde de données à travers le réseau Internet. Ces logiciels vont du logiciel libre à la solution professionnelle. Je vous propose un tour d horizon des diverses solutions ainsi que celle que nous avons choisi et pourquoi. 1. Présentation Les besoins sont multiples et certains préféreront privilégier la facilité de configuration quand d'autres exigeront des fonctionnalités spécifiques à leur réseau. Voici une liste non exhaustive des points qui ont guidé nos choix. 1.1 Les impératifs pour ce genre de logiciels Crash Recovery: La possibilité de reconstruire un disque complet n'est pas toujours évidente. En effet cela peut demander d'avoir créé au préalable une disquette de boot spécifique permettant d'effectuer la restauration. Fonctionnalité juke-box: Si le parc de machines à sauvegarder est très important, la possibilité de faire une session de sauvegarde en utilisant plusieurs bandes est primordiale. Souplesse d'utilisation: Une interface graphique conviviale et une bonne documentation sont un plus indéniable. D'autre part une installation rapide et un programme type client serveur sont très appréciables. Mode ligne de commande: Malgré toutes les fonctionnalités d'une bonne interface graphique, on peut avoir des exigences qui demandent la puissance d'une utilisation en ligne de commande. GPL 1 : Le monde Linux nous a habitués à un haut niveau de logiciel libre, qu'en est il lorsqu'on les compare aux produits commerciaux? 1.2 Les différentes solutions ARKEIA Arkeia est un logiciel de sauvegarde professionnel de type client-serveur. Très facile à installer, il dispose d'une interface graphique très intuitive et d'une documentation complète. La gestion des bandes est pratique et le scheduler souple d'utilisation pour la planification de sauvegardes sur plusieurs postes. On pourra regretter le fait que le cas du crash recovery ne soit pas envisagé. Une version démo limitée à un serveur et 2 client est disponible (http://www.arkeia.com/download). 1 GPL licence de type «copyleft» à l inverse de copyright (jeu de mot), l auteur du logiciel permet l utilisation la modification à condition que celui-ci reste sous la même licence. Tom MIETTE Sébastien MOURET 11 / 31
BRU BRU (Back up and Restore Utility) est un produit développé par Enhanced Software Technologies, Inc. Son interface graphique est simple et fonctionnelle mais ne permet pas de sauvegarder des postes distants(!). Par contre, il existe un mode ligne de commande très riche et bien qui permet d'inclure des commandes bru dans la crontab 1. D'autre part un effort a été fait au niveau du crash recovery: un logiciel complémentaire et gratuit, du nom de CRU (Crash Recovery Utility) est disponible qui permet d'utiliser une disquette de boot pour reconstruire un disque détruit. Une version démo de BRU limitée à 30 jours est disponible. Networkbk Logiciel propriétaire de type client serveur, Networkbk est édité par Visualversion. Facile à mettre en place, pour peu que l'on ait l'environnement java installé, le logiciel se prend en main très rapidement. Les fonctionnalités réseaux sont assez bonnes, mais le logiciel reste assez lent et sujet à de nombreux plantages (!!). De plus, la gestion des bandes est totalement ignorée de même que le mode crash recovery. Pour sa défense le produit donne l'impression d'être encore en phase de développement, ce qui pourrait lui faire pardonner de grosses lacunes. Taper Taper est un logiciel libre développé depuis 95. Simple d utilisation (livré avec Redhat entre autre), il permet d'effectuer des sauvegardes très rapidement depuis un seul poste. Son mode ligne de commande permet de planifier des sauvegardes sur plusieurs machines, mais la gestion des bandes reste assez limitée (pas de fonctionnalité juke-box). Par contre, il est possible d'inclure taper sur des disquettes de crash recovery construites, par exemple, avec yard. Mais le problème n'est pas abordé dans la documentation. Amanda The Advanced Maryland Automatic Network Disk Archiver a été développé pour l'université du Maryland sous licence GPL. Le logiciel est assez ardu à mettre en place, mais est doté d'une documentation abondante (FAQ très riche, articles...). De type client serveur, Amanda est très puissant pour sauvegarder un parc réseau hétérogène. En effet disponible sous différents Unix, il existe même des fonctions pour sauvegarder des postes Windows via samba. On pourra regretter le manque d'une interface graphique, cependant, Amanda n'a pas à rougir devant ses concurrents propriétaires. Et c est pour ces qualités que nous avons décidé de retenir cette solution. Backupedge Backupedge est édité par Microlite. Le logiciel est complet, possédant un mode crash recovery, des fonctionnalités réseaux assez souple et une bonne interface graphique. 1 Crontab programme présent sur un système Unix permettant l'exécution de scripts ou d'autres programmes à intervalle régulier. Comparable au planificateur de tâches sous Windows. Tom MIETTE Sébastien MOURET 12 / 31
Afbackup Le logiciel libre Afbackup a été adapté sur de nombreux Unix. Il permet de sauvegarder simplement plusieurs postes clients depuis un serveur central. Le logiciel est encore en développement et proposera bientôt des fonctionnalités de juke-box. Concurrent sérieux d'amanda il possède tout de même une petite longueur de retard en ce qui concerne la gestion des bandes. D'autre part, il ne possède pas de crash recovery comme son concurrent. Dump/Restore versus tar Un petit mot sur les ancêtres de la restauration de disques, tous deux présents dans tout Unix qui se respecte. Ils possèdent chacun leurs atouts respectifs malgré un manque certain de convivialité. On pourra préférer dump pour ses sauvegardes orientées partitions. Mais le fait est que, leurs options permettent une configuration optimale pour un administrateur confirmé. 2. Pourquoi Amanda? 2.1 Présentation AMANDA (The Advanced Maryland Automatic Network Disk Archiver) est un outil de sauvegarde développé par l'université du Maryland. Jaime Da Silva, le concepteur originel d'amanda, avait comme tout bon administrateur système qui se respecte une collection de scripts pour faire des sauvegardes des machines qu'il administrait. Devant le nombre croissant de machines à sauvegarder il décida de créer AMANDA. 2.2 Les points forts d'amanda En C, distribuable gratuitement. Est basé sur les standards de logiciels de sauvegarde. * Unix dump et restore * Gnu tar * Possibilité d'intégrer d'autres logiciels. Sauvegarde plusieurs machines en parallèle sur un disque tampon (holding disk), écrit les sauvegardes terminées une par une sur la bande aussi rapidement que l'on puisse écrire un fichier sur une bande. Par exemple, une bande LFO de 800 Go avec une vitesse d'écriture de 160Mo/s pour le lecteur sera remplie en 1 heures et demie. Implémente une gestion de bande simple: On ne risque pas d'effacer une mauvaise bande par erreur. Supporte des «tape changer» au travers d'une interface générique. Ainsi on peut très facilement changer une bande sans monopoliser un humain pour le faire. Inclue le support pour une sécurité Kerberos 1 ainsi que des sauvegardes encryptées. Pour récupérer les fichiers, indique les bandes dont vous avez besoin, et trouve la bonne image de sauvegarde sur la bande pour vous. 1 Kerberos protocole de cryptage entre deux machines dans un réseau, comparable au protocole SSH. Tom MIETTE Sébastien MOURET 13 / 31
Inclue une reprise sur incident performante. Produit un rapport incluant toutes les erreurs et l'envoie aux opérateurs de la sauvegarde. Ajuste automatiquement l'ordonnancement des sauvegardes et le niveau des sauvegardes tout en restant dans le cadre prédéfini. Il n'est plus nécessaire de jongler avec l'organisation des sauvegardes lorsque l'on rajoute de nouveaux disques. Inclue un programme de vérification de la configuration sur le serveur ainsi que sur les clients et envoie éventuellement les résultats par courrier électronique. Utilise la compression sur les clients ou sur le serveur. Possèdes beaucoup d'autres options. 2.3 Stratégie maître-esclave AMANDA est basé sur une logique maître-esclave. Le maître possède le périphérique de sauvegarde et donne des ordres aux esclaves pour qu'ils sauvegardent les disques. Il récupère ces sauvegardes et les copie sur le périphérique de sauvegarde. Le serveur (ou maître) Le serveur doit posséder un gros disque et un lecteur de bande ainsi qu'une bonne connectivité réseau. Le disque sert de disque tampon durant la sauvegarde et stocke également des index des différentes sauvegardes. Les clients (ou esclaves). Les esclaves sont une variété de machines UNIX sur lesquelles on peut compiler la partie client d'amanda. Actuellement seules les machines UNIX sont nativement supportées. Des possibilités d'utiliser Samba 1 pour sauvegarder des machines «Windosiennes» sont possibles. Le serveur d'index. Pour chaque partition UNIX sauvegardé AMANDA offre la possibilité de générer un index des fichiers sauvegardés. Ainsi la récupération des fichiers sur les bandes en est grandement simplifiée. Le mécanisme permettant de récupérer les fichiers sera étudié ultérieurement. Les serveurs de bande annexes. On peut également installer des serveurs de bande annexe qui seront utilisé lors de la récupération des fichiers. Ainsi on peut récupérer en parallèle des fichiers de différentes sauvegardes. 1 Samba permet aux systèmes Unix d'accéder aux ressources de ces systèmes et vice-versa. Tom MIETTE Sébastien MOURET 14 / 31
3. Le mécanisme Nous allons maintenant décrire les mécanismes et l'ordonnancement du processus de sauvegarde. 3.1 Sur le serveur Le serveur lance cinq groupes de processus. Le planner. Ce programme «demande» des estimations de la taille de la sauvegarde pour les différents niveaux nécessaires aux différents clients. Avec ces informations il génère un ordonnancement de la sauvegarde. Le driver. Ce programme récupère l'ordonnancement produits par le planner et lance effectivement la sauvegarde en lançant les deux programmes dumper et taper et en les contrôlant tout au long de la sauvegarde. Le dumper. Ce programme gère l'interaction avec un client pour une partition. Un certain nombre de dumper sont lancés en parallèle. Le taper. L'indexeur. Le taper est le programme qui contrôle le lecteur de bande. L'indexeur est chargé de récupérer les tables d'index des sauvegardes si celles-ci ont été demandées. 3.2 Sur les clients. Sur le client il y a également plusieurs programmes qui sont installés. Le plus important est amandad qui se comporte comme un super serveur à l'instar de l'inetd. En effet c'est lui qui récupère tous les ordres du serveur et lance les programmes appropriés. 3.3 L'ordonnancement L'ordonnancement des tâches est donc le suivant. * Sur le serveur le planner est lancé. Celui contacte les amandad qui tournent sur chaque client. Une fois qu'il a récupéré toutes les estimations (réussies ou non) il génère un Tom MIETTE Sébastien MOURET 15 / 31
ordonnancement de sauvegarde qu'il transmet au driver. La phase d'estimation de la sauvegarde est terminée et on peut passer aux choses sérieuses. * Le driver récupère l'ordonnancement et lance un certains nombres de dumpers et un taper. Il affecte à chaque dumper une partition sur une machine à sauvegarder. Le dumper va donc contacter l'amandad qui se trouve sur la machine cliente. Il lui ordonne de commencer la sauvegarde et de lui envoyer le résultat. En même temps que la sauvegarde est effectuée sur le client une liste des fichiers qui sont sauvegardés est générée sur le client. Le dumper recopie la sauvegarde dans le disque tampon au fur et à mesure qu'elle est effectuée. La sauvegarde de la partition terminée le dumper va s'occuper éventuellement de récupérer l'index de la sauvegarde et il se suicide le sentiment du devoir accompli. Le driver donne alors l'ordre au taper de copier sur bande la sauvegarde. Si le taper est déjà occupé la sauvegarde est placée dans une file d'attente. Et tout ce petit monde effectue son travail jusqu'à ce que toutes les sauvegardes soient sur bande. * L'indexeur intervient alors pour récupérer sur les clients les index c'est à dire la liste des fichiers qui ont été sauvegardés. Pour cela il contacte le démon 1 amandad de chaque client qui lui envoie les index. Cette opération est effectuée pour plus de sûreté. En effet si tout fonctionne bien il n'y a plus d'index à récupérer à ce moment là. 3.4 Planification automatique des tâches Tout ceci semble compliqué à paramétrer. En fait, une caractéristique unique d'amanda parmi les logiciels de sauvegarde est que l'organisation de ces phases est laissée à un planificateur qui établit le travail à faire en fonction d'un cahier des charges donné par l'administrateur. Le cahier des charges repose sur plusieurs concepts : Le cycle de sauvegarde (cycle dump) définit le nombre de jours maximal entre les sauvegardes complètes des partitions. Le nombre de cassettes qui seront utilisées pour faire les sauvegardes. Le débit réseau qui est autorisé. Le nombre de sauvegardeurs maximal à faire tourner sur chaque client. Les priorités entre les différentes partitions. AMANDA garde des statistiques sur les performances des sauvegardes passées pour optimiser au mieux l'usage de la bande passante et magnétique en choisissant pour chaque partition si ce sera une sauvegarde complète ou incrémentale d'un certain niveau qui sera effectuée. L'intérêt d'une telle approche est qu'on n'est plus dans la planification statique d'antan : le lundi soir sauvegarde complète de /usr/local et incrémentale de /users, le vendredi soir sauvegarde complète de /users et incrémentale de /usr/local,... qui peut mener à des 1 Un démon (ou daemon) est un processus chargé d'une mission. Tom MIETTE Sébastien MOURET 16 / 31
impossibilités par exemple pour faire loger de front des sauvegardes complètes de partitions qui auraient subit le même jour des modifications importantes. Tout ceci est automatisé par AMANDA mais on peut changer le comportement par défaut pour gérer des cas particuliers comme : * Forcer une sauvegarde complète de certaines partitions par exemple pour le stockage des cassettes ailleurs dans un lieu sécurisé. * Ne faire que des sauvegardes incrémentales si par exemple on a une sauvegarde complète par ailleurs ou qu'on peut récupérer le contenu original en réinstallant le système (le médium du système d'exploitation faisant office de niveau 0). * Ne faire que des sauvegardes complètes sur certaines partitions car c'est trop critique de faire des sauvegardes incrémentales ou le contenu varie trop de toute manière (base de données en production). On comprend aisément l'utilité du nombre de cassettes : si on fait une sauvegarde par jour, cela représente directement le nombre de jours que l'on peut récupérer dans le passé. 3.5 Compression des données Les dérouleurs de bande modernes possèdent un module de compression des données afin d'augmenter la capacité apparente des bandes. Mais AMANDA est aussi capable de comprimer les données au niveau de chaque client, ce qui a plusieurs avantages : * la compression logicielle est souvent meilleure en terme de taux de compression (gzip, bzip2,...) que celle effectuée par le dérouleur mais est aussi plus lente ; * seules les données comprimées passent sur le réseau et donc la pression est moindre ; * lors de la planification AMANDA connaît le taux de compression effectif pour chaque partition et peut mieux remplir les bandes avec moins de risque de débordement. Comme la compression est parallélisée sur tous les clients le débit reste conséquent. Néanmoins, si on a certaines machines pas très puissantes, on peut marquer les partitions de celles-ci comme devant être comprimées par le dérouleur et non AMANDA. Un point subtil est que si on demande la compression matérielle du dérouleur de bande, elle sera aussi appliquée aux partitions déjà comprimées logiciellement. Or il est peu probable que la compression matérielle supplémentaire arrive à en comprimer quelque chose mais il restera le surcoût des entêtes de compression. Du coup la capacité apparente de la bande diminuera un peu... 3.6 Formats de sauvegarde AMANDA utilise les outils disponibles sur les clients pour faire des images de sauvegarde et ces images sont mises par le serveur dans un format très simple. Tom MIETTE Sébastien MOURET 17 / 31
Mais il faut choisir pour chaque partition quel va être l'outil utilisé, typiquement GNU tar 1 ou un outil plus proche du système de fichier, dump. Rapidement, les avantages et inconvénients de chaque approche : dump : * spécifique à un système de fichiers, voire à un système d'exploitation. Gênant pour faire des sauvegardes portables et éternelles ; * mode de restauration interactive ; * ne change pas les dates des fichiers ; tar : * format portable, documenté, logiciel libre. On pourra relire les sauvegardes sur une autre machine (si les bandes ne sont pas endommagées et qu'il reste un lecteur en état de marche...) ; * pas de conflit sur le fichier de gestion incrémentale des sauvegardes. Permet facilement de mélanger plusieurs instances d'amanda (archivage + sauvegardes) ; 3.7 Changeur de bandes AMANDA ne peut contrôler qu'un dérouleur de bande mais celui-ci peut avoir un système de chargement automatique. L'intérêt primordial est l'automatisation complète de la sauvegarde et la possibilité de remplir plusieurs bandes par sauvegarde. Mais cela a d'autres effets de bord qui se traduisent par une quasi disparition des problèmes d'écriture et donc de l'emploi de la commande amflush. En effet, si AMANDA n'a exceptionnellement plus de place pour écrire sur la bande (une ou des partitions ont été fortement modifiées au cours de la sauvegarde) ou qu'il y a un problème en écriture la bande est déchargée et la suivante est utilisée. L'inconvénient néanmoins d'un changeur de bande est que si la pièce qui le contient brûle, toutes les cassettes dedans disparaissent alors que si on n'en a pas, comme on se déplace pour changer les cassettes on peut plus naturellement les entreposer dans des lieux distants et différents. 3.8 Configuration Dans la pure tradition unixienne 2, tout est fait avec des fichiers textes. La configuration est tellement simple qu'il n'y a pas d'interface graphique de configuration ou de contrôle. Le rajout d'un disque de machine à sauvegarder se traduit par 1 GNU tar programme permettant de créer des archives. On compactes un ensemble de fichiers et/ou répertoires en un seul fichier. 2 Dans les systèmes de type Unix tout est considéré comme un fichier. Tom MIETTE Sébastien MOURET 18 / 31
une ligne à rajouter dans un fichier disklist central. Nous verrons dans les parties suivantes la configuration en détails. IV. Installation et configuration du logiciel Packages requis : dump, amanda-server (sur le serveur), amanda-client (sur toute machine faisant l'objet d'une sauvegarde) 1. Configuration d'une sauvegarde : le serveur Sur le serveur, on installe les packages dump et amanda-server qui descend le package amanda-common. Un utilisateur backup est ajouté au système, propriétaire des fichiers de configuration et du périphérique lecteur de bandes ; backup lancera les taches de sauvegarde via cron 1. Attention, ce sera root qui procédera aux restaurations, lancées depuis les clients avec amrecover, et non backup dont ce n'est pas le travail et qui n'aura pas les droits pour le faire. Toutefois, on fera toutes les manipulations de cette section sous l'utilisateur backup et non root. Comme le répertoire /usr/sbin, qui n'est pas dans le PATH de backup, contient toutes les commandes d'amanda (amcheck, amdump, amlabel, etc..), il est impossible que backup trouve les commandes qu'il est appelé à utiliser constamment. Pour y remédier, on placera la ligne «export PATH=$PATH:/usr/sbin» dans le fichier.profile du home de backup (/var/backups). Commençons par vérifier le fonctionnement du matériel et les droits de l'utilisateur backup Celui ci doit faire partie des groupes disk, tape et backup. Le périphérique de sauvegarde s'appelle dev/st0, mais le périphérique /dev/nst0 sera impérativement utilisé par défaut dans les sauvegardes d'amanda (il ne rembobine pas la bande). Ces deux périphériques doivent avoir les permissions suivantes : crw-rw---- 1 root tape 9, 0 Mar 14 2002 /dev/st0 crw-rw---- 1 root tape 9, 128 Mar 14 2002 /dev/nst0 Deux commandes simples permettent de vérifier que backup peut faire fonctionner le lecteur LFO : «mt -f /dev/st0 rewind» et «mt -f /dev/st0 eject». Nous allons mettre en place une sauvegarde incrémentale hebdomadaire qui tourne sur une bande, nous offrant une antériorité d'un mois ; nous l'appellerons config, et la placerons sur le serveur où nous avons réservé une partition pour /var/spool. Nous sauvegarderons les données présentes sur les machines du réseau tous les Vendredis soirs. Les fichiers définissant la sauvegarde se trouvent dans /etc/amanda/config (où le répertoire config désigne le nom de notre sauvegarde, que nous allons utiliser en permanence). Créons dans /etc/amanda un répertoire config à coté de celui qui a été crée à l'installation, dont les permissions sont les suivantes : 1 Cron programme qui permet aux utilisateurs des systèmes Unix d'exécuter automatiquement des scripts, des commandes ou des logiciels à une date et une heure spécifiées à l'avance, ou selon un cycle défini à l'avance Tom MIETTE Sébastien MOURET 19 / 31
drwxr-xr-x 2 backup backup 4096 Mar 18 20:30 config Copions dans ce répertoire le contenu du répertoire DailySet1, configuration de sauvegarde par défaut : * amanda.conf, contient la quasi totalité de la configuration de la sauvegarde * disklist, contient la liste des disques des machines à sauvegarder. Le fichier /etc/amanda/config/amanda.conf, clairement expliqué en anglais, définit notre sauvegarde : il faut en renseigner bien rigoureusement chaque ligne. Nous indiquerons à chaque fois qu'un certain nombre de répertoires sont à créer manuellement ; il sera judicieux de créer ces répertoires au moment où on les déclare dans le fichier de manière à ne pas les oublier par la suite. org "Sauvegardes" mailto "root" # your organization name for reports # space separated list of operators at your site Pour les rapports envoyés par mail à l'issue de chaque sauvegarde. dumpuser "backup" # the user to run dumps under L utilisateur chargé de la sauvegarde. inparallel 1 netusage 99000 # maximum dumpers that will run in parallel # maximum net bandwidth for Amanda, in KB per sec A ajuster selon la puissance du serveur et la bande passante du réseau en tenant compte de son occupation à l'heure où les sauvegardes sont réalisées, d'où l'intérêt de les faire la nuit en utilisant la totalité des 1 Gbits permis par le switch. dumpcycle 7 weeks # the number of days in the normal dump cycle Durée d'un cycle de sauvegarde tapecycle 1 tapes # the number of tapes in rotation Nombre de bandes en rotation pendant ce cycle. bumpsize 200 MB # minimum savings (threshold) to bump level 1 -> 2 bumpdays 1 # minimum days at each level bumpmult 4 # threshold = bumpsize * (level-1)**bumpmult L'incrémentalité de la sauvegarde, à affiner à l'usage selon le volume de données sauvegardées et la capacité des bandes. #tpchanger "no-changer" # the tape-changer glue script, see TAPE.CHANGERS Tom MIETTE Sébastien MOURET 20 / 31
Tout ce qui parle de «tape changer» concerne un système de robot qui change automatiquement les bandes, qui peuvent être plusieurs pour une même sauvegarde. Ce sont des systèmes très haut de gamme, nous n en utiliserons pas ici, un humain se chargera de changer la bande au moment voulu. tapedev "/dev/nst0" # Linux @ tuck, important: norewinding Le périphérique de sauvegarde, il est essentiel de ne pas rembobiner la bande. Le périphérique /dev/st0 ne convient donc pas. tapetype HP-DDS-4 # what kind of tape it is Le type de bande utilisée, tel que nous le définirons ci dessous (type HP-DDS-4). labelstr "^config[0-9][0-9]*$" # label constraint regex: all tapes must match Le nom que nous donnerons à nos bandes, qui s'appelleront impérativement config01, config02, etc. diskdir "/var/spool/backup" # where the holding disk is Le répertoire du disque dur que nous utiliserons comme zone de stockage temporaire pendant la sauvegarde, avant l'écriture proprement dite sur la bande. Deux lignes plus bas, on remarque que plusieurs disques de ce type peuvent être définis. disksize 20000 MB # how much space can we use on it La quantité d'espace disque utilisable pour ce répertoire qui n'est pas nécessairement une partition, on peut le partager avec d'autres spools. Ce répertoire devra être crée à la main avec les permissions suivantes : drwxr-xr-x 3 backup backup 4096 Mar 25 20:30 /var/spool/backup infofile "/data/amanda/curinfo" logfile "/data/amanda/config/log" # database filename # log filename L'emplacement de la base de données des fichiers sauvegardés, leur historique, etc. indexdir "/data/amanda/config/index" L'emplacement des fichiers d'index (la liste de ce qui est sauvegardé). Quelques mégaoctets sont nécessaires pour cette base de données, il n'est pas pertinent en cas d'occupation disque importante de placer cela à coté des fichiers de configuration. Ce répertoire, crée à la main, a ces permissions : drwxrwx--- 5 backup backup 4096 May 13 2004 /data/amanda Tom MIETTE Sébastien MOURET 21 / 31
On créera ensuite, dans ce répertoire, un sous répertoire qui portera le nom de notre sauvegarde (config). L'arborescence de ce sous répertoire sera, elle, créée automatiquement lors de la première sauvegarde, avec un message d'avertissement lors de la vérification de la configuration (commande amcheck). Cette base de données est essentielle au fonctionnement d'amanda, puisqu'elle contient l'index des fichiers qui ont été sauvegardés et la bande où ils se trouvent. C'est la raison pour laquelle il ne faut jamais sauvegarder un disque sur lui même, de manière à préserver cette base de données en cas de crash disque. La documentation indique toutefois une procédure de restauration, indiquée comme particulièrement difficile, même en ce cas (cf. /usr/share/doc/packages/amanda-common/restore.gz). Vient ensuite une longue liste de définitions de types de bandes magnétiques, il est fort probable que cette liste ne comprendra pas celles qui ont été achetées avec le lecteur LFO :). La commande tapetype, au traitement extrêmement long, permet de générer une description de bande pour Amanda. On trouve facilement avec Google une définition des caractéristiques de nos bandes fournie par d'autres utilisateurs. Le rapport reçu par mail à l'issue de la première sauvegarde permettra de vérifier la conformité de la définition des bandes dans Amanda avec leur capacité réelle. Voici une entrée pour les bandes de notre lecteur LFO trouvée en quelques instants sur Internet : define tapetype HP-DDS-4 { length 17021 mbytes filemark 403 kbytes speed 1578 kps } Vient enfin la définition proprement dite de la sauvegarde que nous allons réaliser. L'auto documentation du fichier expose les différentes options avec un nombre conséquent d'exemples. Nous allons définir un nouveau type de sauvegarde que nous appellerons «hebdo» : define dumptype hebdo { compress-best priority high index } Nous compressons le mieux possible puisque nous disposons du temps pour le faire (il y a peu de gens qui travaillent la nuit ) ; l'option index précise que nous voulons que la liste des fichiers sauvegardés soit indexée. Enfin la priorité est définie comme haute, elle pourrait être mise à «low» ou «medium» par rapport à d'autres disques que nous sauvegarderions en même temps, mais avec un autre type de sauvegarde car ces disques seraient jugés plus importants. La différence est que plus une sauvegarde est importante, plus elle sera prioritaire dans l'occupation de l'espace disque temporaire, ce qui est très utile en mode dégradé, lorsque le lecteur n'est pas disponible (vraisemblablement parce qu'on a oublié de changer la bande) et que tout va rester sur le disque en attendant un dump définitif (commande amflush). Tom MIETTE Sébastien MOURET 22 / 31
Le fichier /etc/amanda/config/disklist contient la liste des disques23 que nous désirons sauvegarder, le fichier documente lui même abondamment le type de partitions prises en charge, y compris vfat. La syntaxe est simple : on indique sur une ligne le nom de la machine, la partition à sauvegarder et le type de sauvegarde tel que défini en dernier dans le fichier amanda.conf. Pour nous : abraracourcix sda4 abraracourcix sdb1 ash hda5 hebdo hebdo hebdo C'est tout! :) 2. Configuration d'une sauvegarde : les clients Amandad, logiciel client du serveur Amanda, est lancé automatiquement sur chaque machine cliente (celles dont on désire sauvegarder une partition) par le serveur en tant que service d'inetd dès que démarre la sauvegarde. L'installation du package amanda-client a placé cette ligne dans le fichier etc/inetd.conf : amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad Il faut cependant que chaque machine, serveur comme cliente, soit autorisée à communiquer avec les autres pendant la sauvegarde mais également pendant la restauration. Ces autorisations sont définies dans les fichiers.amandahosts situés dans le répertoire personnel de l'utilisateur backup (/var/backups) sur chaque machine. La syntaxe de ces fichiers peut donner lieu à un certain énervement :), et requiert de bien comprendre qui accède à quelle machine, en tant que root ou en tant que backup (rappellons que seul root peut restaurer mais ne doit pas sauvegarder). Sur le serveur de sauvegarde andromede, cette configuration est requise si nous sauvegardons les machines abraracourcix et ash, puisque backup réalise la sauvegarde et root assure la restauration : localhost backup abraracourcix.mp-soa.net root abraracourcix.mp-soa.net backup ash.mp-soa.net root ash.mp-soa.net backup Sur une machine cliente, il suffira d'indiquer : localhost backup andromede.mp-soa.net backup 3. La première sauvegarde et restauration Nous pouvons formater une bande qui va nous servir de test pour la sauvegarde «config», que nous allons appeler «config01», au moyen de la commande amlabel config Tom MIETTE Sébastien MOURET 23 / 31
config01. Si cette bande a déjà été utilisée dans la même sauvegarde, on pourra forcer son effacement au moyen de l'option -f. La commande amcheck config, lancée en tant que backup sur le serveur, nous permet de tester la validité de la sauvegarde que nous avons appelée «config». En voici une sortie correcte : andromede:~$ amcheck config Amanda Tape Server Host Check ----------------------------- Holding disk /data/backup: 2963940 KB disk space available, that's plenty NOTE: skipping tape-writable test Tape config01 label ok Server check took 8.637 seconds Amanda Backup Client Hosts Check -------------------------------- Client check: 2 hosts checked in 0.101 seconds, 0 problems found Tous les problèmes seront indiqués très clairement : bande absente, non valide, machine indisponible ou avec laquelle il est impossible de communiquer, etc. La documentation du package amanda-common contient une FAQ qui détaille les problèmes les plus courants (en particulier une entrée d'inetd.conf incorrecte ou un fichier.amandahosts mal renseigné). Les logiciels composant Amanda créent des fichiers temporaires dans /tmp, ils apportent une aide majeure pour corriger les problèmes. Lorsque tout est correct, il suffit de lancer une sauvegarde de test avec la commande amdump config. On voit le système rendre tout de suite la main, les démons amandad se lancer sur les machines clientes et appeler les utilitaires de backup, de compression et d'envoi par réseau de la sauvegarde. Sur le serveur, le répertoire /var/spool/backup se remplit de fichiers temporaires qui grossissent en taille, puis vont être écrits sur la bande. Lorsque tout est fini, l'utilisateur défini dans la sauvegarde reçoit un mail qui l'informe du déroulement des opérations et des statistiques de la sauvegarde, en particulier les pourcentages d'occupation des bandes et les taux de compression. Le message précise en premier lieu le nom de la prochaine bande qu'attend Amanda. Nous pouvons donc tester le fonctionnement de la restauration avec l'utilitaire amrecover. Il y a deux utilitaires de restauration : amrestore permet de restaurer l'ensemble d'une partition qui a été détruite ou altérée, ce que le RAID 1 est là pour éviter. D'autre part l'utilitaire amrecover permet de restaurer simplement certains fichiers qui ont été perdus ou altérés par maladresse. C'est la raison pour laquelle nous faisons des sauvegardes. Amrecover sera lancé en tant que root (et non backup) sur la machine cliente, à la racine du système de fichiers où se trouve ce que l'on veut restaurer. Imaginons que nous fassions un test sur le fichier galantine.sxi, effacé par mégarde du répertoire /home/formateurs sur la machine abraracourcix. Nous nous logons donc en root sur notre serveur et nous nous 1 RAID technologie permettant de stocker des données sur de multiples disques durs, en général de manière redondante enfin de conserver l intégrité d un disque dur en cas de panne. Tom MIETTE Sébastien MOURET 24 / 31