Red Hat Enterprise Linux 3: Introduction à l'administration système | ||
---|---|---|
Précédent | Chapitre 8. Préparation à un sinistre | Suivant |
En matière de sinistres et de récupération post-sinistre, peu de choses ont une influence directe sur un système d'exploitation particulier. En effet, aucun des ordinateurs d'un centre de données inondé ne pourront fonctionnés, qu'ils exécutent Red Hat Enterprise Linux ou tout autre système d'exploitation. Toutefois, certaines parties de Red Hat Enterprise Linux ont un lien avec certains aspects spécifiques de la récupération post-sinistre ; ces dernières sont abordées dans cette section.
En tant que revendeur de logiciels, Red Hat offre un certain nombre d'options d'assistance pour ses produits, y compris Red Hat Enterprise Linux. En ce moment, en lisant ce manuel, vous utilisez l'outil d'assistance le plus élémentaire : la documentation. De la documentation pour Red Hat Enterprise Linux est disponible sur le CD-ROM de documentation de Red Hat Enterprise Linux (qui peut être installé sur votre système pour un accès rapide), sous forme écrite et sous forme électronique sur le site Web de Red Hat à l'adresse suivante : http://www.redhat.com/docs/.
Des options d'assistance autonomes existent également par le biais des nombreuses listes de diffusion hébergées par Red Hat (disponibles à l'adresse suivante : https://listman.redhat.com/mailman/listinfo/). Ces listes de diffusion puisent dans le savoir de la communauté des utilisateurs de Red Hat et dans les nombreuses listes placées sous le contrôle de membres du personnel de Red Hat qui apportent des contributions en fonction de leur disponibilité. D'autres ressources sont également disponibles sur la page principale d'assistance de Red Hat figurant à l'adresse suivante : http://www.redhat.com/apps/support/.
Il existe également des options d'assistance plus complètes au sujet desquelles vous trouverez des informations détaillées sur le site Web de Red Hat.
Red Hat Enterprise Linux est vendu avec de nombreux programmes différents pour la sauvegarde et la restauration de données. Ils ne constituent toutefois pas en eux-mêmes une solution complète de sauvegarde. Ceci étant, ils peuvent tout à fait être utilisés pour former le noyau d'une telle solution.
![]() | Remarque |
---|---|
Comme nous le faisions remarqué dans la Section 8.2.6.1, la plupart des ordinateurs basés sur une architecture PC standard ne disposent pas de la fonctionnalité leur permettant de démarrer directement à partir d'une bande de sauvegarde. Par conséquent, Red Hat Enterprise Linux n'est pas en mesure d'effectuer un amorçage par bande lorsqu'il est exécuté sur un tel matériel. Il est toutefois possible d'utiliser votre CD-ROM Red Hat Enterprise Linux comme un disque de secours ; pour de plus amples informations sur le sujet, reportez-vous au chapitre sur le mode de secours du Guide d'administration système de Red Hat Enterprise Linux. |
L'utilitaire tar est très connu parmi les administrateurs de systèmes UNIX. C'est la méthode d'archivage préférée pour partager entre différents systèmes des bits de code source et des fichiers. L'implémentation de tar comprise dans Red Hat Enterprise Linux est GNU tar, une des implémentations de tar les plus riches en fonctionnalités.
En utilisant tar, la sauvegarde du contenu d'un répertoire peut être aussi simple que l'exécution d'une commande semblable à celle figurant ci-dessous :
tar cf /mnt/backup/home-backup.tar /home/ |
Cette commande crée un fichier d'archive nommé home-backup.tar dans /mnt/backup/. L'archive elle-même renferme de contenu du répertoire /home/ .
La taille du fichier d'archive créé sera presque aussi grande que celle de l'ensemble des données sauvegardées. Selon le type des données sauvegardées, le compression des données peut permettre de réduire considérablement la taille du fichier d'archive. Ce dernier peut être compressé en ajoutant une seule option à la commande précédente, comme le montre la commande ci-dessous :
tar czf /mnt/backup/home-backup.tar.gz /home/ |
Le fichier d'archive home-backup.tar.gz ainsi créé est désormais compressé avec gzip[1].
La commande tar accepte une variété d'options ; afin d'obtenir de plus amples informations sur le sujet, lisez la page de manuel de tar(1).
L'utilitaire cpio est un autre programme UNIX traditionnel. C'est un excellent programme pour effectuer des tâches générales comme le transfert de données d'un endroit à un autre et en tant que tel, peut servir également de programme de sauvegarde.
Le comportement de cpio et légèrement différent de celui de tar. Contrairement à tar, cpio lit le nom des fichiers qu'il doit traiter par le biais d'entrées standard. Pour dresser une liste de fichiers pour cpio, une méthode courante est utilisée ; cette dernière consiste à utiliser des programmes comme find et à tuber la sortie vers cpio, comme le montre la commande ci-dessous :
find /home/ | cpio -o > /mnt/backup/home-backup.cpio |
Suite à cette commande, un fichier d'archive cpio est créé (renfermant tout le contenu de /home/) et placé dans le répertoire /mnt/backup sous le nom home-backup.cpio.
![]() | Astuce |
---|---|
Étant donné que la commande find dispose d'un vaste ensemble d'options pour la sélection de fichiers, des sauvegardes sophistiquées peuvent facilement être créées. Par exemple, la commande suivante effectue uniquement la sauvegarde des fichiers qui n'ont pas été touchés au cours de l'année écoulée : |
find /home/ -atime +365 | cpio -o > /mnt/backup/home-backup.cpio |
De nombreuses options peuvent être utilisées avec cpio (et find) ; afin d'obtenir de plus amples informations sur le sujet, lisez les pages de manuel de cpio(1) et de find(1)
Les programmes dump et restore sont les équivalents Linux des programmes UNIX portant le même nom. En tant que tels, de nombreux administrateurs système ayant une expérience de systèmes UNIX peuvent estimer que dump et restore sont des options tout à fait viables pour un bon programme de sauvegarde sous Red Hat Enterprise Linux. Malheureusement, la conception du noyau Linux a évoluée bien au-delà de la conception de dump. Ci-après figure un commentaire de Linus Torvald sur le sujet :
From: Linus Torvalds To: Neil Conway Subject: Re: [PATCH] SMP race in ext2 - metadata corruption. Date: Fri, 27 Apr 2001 09:59:46 -0700 (PDT) Cc: Kernel Mailing List <linux-kernel At vger Dot kernel Dot org> [ linux-kernel added back as a cc ] On Fri, 27 Apr 2001, Neil Conway wrote: > > I'm surprised that dump is deprecated (by you at least ;-)). What to > use instead for backups on machines that can't umount disks regularly? Note that dump simply won't work reliably at all even in 2.4.x: the buffer cache and the page cache (where all the actual data is) are not coherent. This is only going to get even worse in 2.5.x, when the directories are moved into the page cache as well. So anybody who depends on "dump" getting backups right is already playing Russian roulette with their backups. It's not at all guaranteed to get the right results - you may end up having stale data in the buffer cache that ends up being "backed up". Dump was a stupid program in the first place. Leave it behind. > I've always thought "tar" was a bit undesirable (updates atimes or > ctimes for example). Right now, the cpio/tar/xxx solutions are definitely the best ones, and will work on multiple filesystems (another limitation of "dump"). Whatever problems they have, they are still better than the _guaranteed_(*) data corruptions of "dump". However, it may be that in the long run it would be advantageous to have a "filesystem maintenance interface" for doing things like backups and defragmentation.. Linus (*) Dump may work fine for you a thousand times. But it _will_ fail under the right circumstances. And there is nothing you can do about it. |
En raison de ce problème, l'utilisation de dump/restore sur des systèmes de fichiers montés est fortement déconseillée. Toutefois, dump a été conçu à l'origine pour sauvegarder des systèmes de fichiers non montés ; par conséquent, dans des situations où il est possible de déconnecter un système de fichiers à l'aide de la commande umount, dump demeure une technologie de sauvegarde tout à fait viable.
AMANDA est une application client/serveur de sauvegarde élaborée par l'Université du Maryland. En ayant une architecture client/serveur, un seul serveur de sauvegarde (généralement un système relativement puissant disposant d'une grande quantité d'espace libre sur les disques rapides et configuré avec le périphérique de sauvegarde souhaité) peut sauvegarder de nombreux systèmes clients, qui n'ont eux besoin que du logiciel client AMANDA.
Cette approche en matière de sauvegardes est tout à fait logique dans la mesure où elle regroupe sur un seul système, toutes les ressources nécessaires pour la création de sauvegardes, au lieu de nécessiter du matériel supplémentaire pour chaque système ayant besoin de services de sauvegarde. La conception d'AMANDA sert également à centraliser l'administration des sauvegardes, simplifiant par là-même considérablement, la vie de l'administrateur système.
Le serveur AMANDA gère un ensemble de supports de sauvegarde et effectue une rotation de leur utilisation au sein de cet ensemble, afin d'assurer que toutes les sauvegardes sont conservées pour la durée déterminée par l'administrateur. Tout support est pré-formaté avec des données qui permettent à AMANDA de détecter si le bon support est disponible ou non. De plus, AMANDA peut être interfacé avec des dispositifs de changement de supports robotisés, permettant par là-même de compètement automatiser les opérations de sauvegarde.
AMANDA peut utiliser soit tar soit dump pour effectuer les sauvegardes (bien que sous Red Hat Enterprise Linux, l'utilisation de tar soit préférable, en raison des problèmes avec dump mentionnés dans la Section 8.4.2.3). En tant que tel, les sauvegardes effectuées avec AMANDA n'ont pas besoin d'AMANDA pour la restauration des fichiers — un avantage indéniable.
Au niveau de son utilisation, AMANDA est généralement programmé pour être exécuté une fois par jour pendant la période de temps allouée aux opérations de sauvegarde dans le centre de données. Le serveur AMANDA se connecte aux systèmes clients et guide les clients dans la création des sauvegardes selon l'estimation de leur taille. Une fois ces estimations disponibles, le serveur établit un programme déterminant automatiquement l'ordre selon lequel les systèmes seront sauvegardés.
Une fois que les sauvegardes commencent effectivement, les données sont envoyées par le réseau du client au serveur, où elles sont stockées sur un disque intermédiaire. Une fois qu'une sauvegarde est terminée, le serveur commence à effectuer l'enregistrement du disque intermédiaire sur le support de sauvegarde. En même temps, d'autres clients envoient leurs sauvegardes sur le serveur afin qu'elles soient elles aussi stockées sur le disque intermédiaire. Ce processus crée un flux continu de données disponibles pour l'enregistrement sur le support de sauvegarde. Au fur et à mesure que les sauvegardes sont enregistrées sur le support de sauvegarde, elles sont supprimées du disque intermédiaire du serveur.
Une fois que toutes les sauvegardes sont terminées, un rapport détaillant l'état des sauvegardes est envoyé à l'administrateur système sous forme d'email, rendant par là-même la révision simple et rapide.
Dans le cas où il serait nécessaire de restaurer des données, AMANDA contient un programme utilitaire qui permet à l'opérateur d'identifier le système de fichiers, la date et le(s) nom(s) des fichiers. Une fois cette opération terminée, AMANDA identifie le bon support de sauvegarde et ensuite localise et restaure les données désirées. Comme nous l'avons mentionné précédemment, AMANDA est conçu de telle manière qu'il puisse restaurer des données même sans l'assistance d'AMANDA, bien que l'identification du support approprié s'effectuera alors selon un processus manuel d'une certaine lenteur.
Cette section n'a couvert qu'une partie infime des concepts les plus élémentaires d'AMANDA. Si vous souhaitez effectuer des recherches plus approfondies sur AMANDA, nous vous suggérons de commencer par la lecture de la page de manuel relative à amanda(8).
[1] | L'extension .gz est typiquement utilisée pour indiquer que le fichier a été compressé à l'aide de gzip. Parfois .tar.gz est abrégé en .tgz afin que le nom des fichiers conserve un longueur acceptable. |
Précédent | Sommaire | Suivant |
Récupération suite à un sinistre | Niveau supérieur | Ressources supplémentaires |