Sauvegarde de XenServer avec Bacula. Comment sauvegarder l’hyperviseur Citrix ?

Citrix Hypervisor (anciennement appelé XenServer) est une plate-forme de gestion de virtualisation complète, dotée d’une variété de capacités et de types d’infrastructure pris en charge. Citrix Hypervisor est le résultat d’un rebranding de son produit précédemment connu sous le nom de XenServer.

Informations générales

Bacula Enterprise offre une intégration native avec Citrix Hypervisor via un plugin spécifique (ou ‘Module’ ; les termes sont interchangeables dans ce contexte). Ce niveau d’intégration permet aux utilisateurs de Bacula Systems d’effectuer diverses opérations de sauvegarde et de restauration de XenServer à différents niveaux avec Citrix Hypervisor, quelle que soit la taille ou la complexité du centre de données en question. Il existe également un potentiel particulièrement important en termes de flexibilité et de personnalisation de la solution, notamment en ce qui concerne les emplacements de déploiement, les types de données, les méthodes de restauration, etc.

La sauvegarde et la restauration de l’hyperviseur XenServer Citrix de Bacula Enterprise offre une variété de fonctionnalités différentes, notamment :

• Des sauvegardes complètes, incrémentielles et différentielles au niveau des images XenServer
• Des capacités de sauvegarde en ligne avec une technologie de snapshot pour les VM invitées
• Des capacités de restauration d’images complètes de VM
• La prise en charge des anciens formats et types de sauvegarde
• La possibilité d’effectuer des instantanés basés sur VSS pour les VM invitées
• Une option pour changer le répertoire cible pour une archive VM, et bien plus encore.

Sauvegarde et récupération de XenServer sans logiciel tiers

Avant de passer en revue les capacités de Bacula avec le XenServer, il est également important de mentionner qu’il existe un moyen de faire des opérations de sauvegarde et de restauration avec Xen lui-même. Il y a cependant quelques limitations à cela – les sauvegardes de serveurs peuvent prendre beaucoup d’espace de stockage, vous pouvez avoir besoin de redémarrer avec le CD d’installation original pour effectuer un processus de restauration complet, et vous ne devez pas créer de sauvegardes du domaine de contrôle du XenServer (domaine 0).

Voici comment se déroule le processus de sauvegarde :

1. Sélectionnez le serveur désigné dans le panneau Ressources, cliquez sur le menu Serveur et allez à la ligne Sauvegarder le serveur….
2. Localisez et spécifiez le dossier que vous voulez utiliser comme emplacement de stockage du fichier de sauvegarde, entrez le nom du fichier et cliquez sur Enregistrer. Le processus de sauvegarde va commencer. Vous pouvez également utiliser l’onglet Logs pour voir le processus de la sauvegarde.

Et c’est à peu près tout, l’ensemble du processus de sauvegarde ne comporte que deux étapes. Le processus de restauration est également relativement simple :

1. Tout d’abord, vous devez localiser ce même menu Serveur et cliquer sur la ligne Restaurer à partir de la sauvegarde….
2. Dans le menu suivant, localisez le fichier de sauvegarde que vous voulez restaurer.
3. Utilisez le CD d’installation de XenServer pour redémarrer le serveur et terminer le processus de restauration.

Installation du client Bacula sur chaque VM invitée

Lorsqu’il s’agit d’opérations de sauvegarde et de restauration de VM XenServer avec Bacula, il y a plusieurs approches différentes, et c’est un peu plus sophistiqué que la méthode originale. Tout d’abord, nous allons voir comment Bacula et Citrix peuvent fonctionner avec des VMs invitées et quelles stratégies de sauvegarde XenServer fonctionnent pour celles-ci.

Cette stratégie particulière fonctionne en installant un Bacula Enterprise File Daemon sur chaque VM invitée, traitée comme si elle était un client physique normal. Vous devrez tirer parti manuellement des capacités de planification, de priorisation et d’exécution parallèle des tâches de Bacula pour optimiser l’utilisation des E/S de l’hyperviseur Citrix et éviter divers problèmes et bottlenecks.

L’installation d’un File Daemon de Bacula Enterprise sur une VM particulière vous permet de la gérer comme un serveur physique, ce qui permet d’utiliser un certain nombre de fonctionnalités utiles de Bacula Enterprise, notamment :

• La compression au niveau des fichiers
• La vérification des tâches
• La précision des sauvegardes
• La restauration de fichiers individuels
• L’exclusion de fichiers ou de répertoires spécifiques
• Vérification de la somme de contrôle pour rechercher des logiciels espions ou des virus.

Utilisation du module Citrix Hypervisor pour créer des sauvegardes d’images

La stratégie de niveau image permet au module Citrix Hypervisor de Bacula d’utiliser le disque brut pour créer des sauvegardes. Il n’est pas non plus nécessaire d’installer un Daemon Bacula sur chaque VM pour que cette technique fonctionne. Le module Xen tire parti de l’API de XenServer pour localiser et sauvegarder le contenu de chacune de vos VM en utilisant la technologie snapshot et les méthodes vm-export/vm-import.

Cette méthode permet d’économiser d’importantes ressources car Bacula n’a pas besoin de « parcourir » le système de fichiers de chaque VM, ce qui permet d’alléger la charge de travail de l’infrastructure de l’hyperviseur Citrix en général. D’un autre côté, comme ce type de sauvegarde de VM XenServer sauvegarde littéralement tout ce qui se trouve sur une VM particulière, cela inclut également les fichiers inutiles dont vous n’avez pas vraiment besoin dans votre sauvegarde, comme les fichiers temporaires ou les fichiers d’échange. Cependant, c’est aussi un avantage, car les fichiers de configuration de la VM sont également sauvegardés par cette méthode, ce qui permet une restauration beaucoup plus facile de la VM.

Processus de sauvegarde

Le processus de base de création d’une sauvegarde d’une seule VM à l’aide du module de sauvegarde VM de XenServer comporte quatre étapes principales :

• La suppression de l’ancienne version
• Création d’un nouvel instantané de la VM et étape de préparation de la sauvegarde
• Exécution de la commande vm-export et sauvegarde des données sur un stockage Bacula
• Suppression du snapshot dès que la sauvegarde est terminée.

Les états de la VM invitée, qu’elle soit en fonctionnement ou à l’arrêt, conviennent à l’exécution d’un processus de sauvegarde. Les seuls instantanés qui seraient considérés comme anciens par le système sont ceux qui correspondent au modèle spécifique – BaculaSnapshot_<UUID>_JobID_<NR>. Ces snapshots sont automatiquement supprimés au début du processus de sauvegarde Xen, il est donc recommandé d’éviter de créer des snapshots manuels qui correspondent à ce modèle de dénomination. La console d’état du module Citrix Hypervisor vous offrirait les informations sur les VM invitées qui sont actuellement sauvegardées, les étapes de chaque sauvegarde XenServer, les activités des instantanés, les sauvegardes qui ont été supprimées, etc. Vous pouvez voir un exemple de ces informations ci-dessous :

Chaque VM invitée participant au processus signifie un fichier de sauvegarde XenServer supplémentaire, nommé comme suit :

Il y a également un certain nombre de paramètres qui sont utilisés pour définir des parties spécifiques et des variations du processus de sauvegarde Xen.

• vm=<name-label> représente le nom d’une VM invitée que vous allez sauvegarder. Toutes les correspondances avec le nom entre parenthèses seront sauvegardées. Le paramètre lui-même est facultatif et n’est pas nécessaire pour que l’ensemble du processus fonctionne.
• uuid=<uuid> spécifie un UUID de la VM invitée spécifique. L’UUID est l’identifiant unique universel – un numéro de 128 bits qui identifie les informations dans divers systèmes. Le paramètre lui-même est facultatif et n’est pas nécessaire pour que l’ensemble du processus fonctionne.
• include=<name-label-regex> est une liste de noms de VM invitées à sauvegarder, exprimée par une syntaxe régulière. Toutes les VM invitées dont les noms correspondent seront sauvegardées. Le paramètre lui-même est facultatif et n’est pas nécessaire pour que l’ensemble du processus fonctionne.
• exclude=<name-label-regex> est une liste de noms de VM invitées à exclure du processus de sauvegarde, exprimée via une syntaxe régulière. Toutes les correspondances seront entièrement exclues du processus de sauvegarde. N’affecte pas les paramètres vm= ou uuid=. Le paramètre lui-même est facultatif et n’est pas nécessaire pour que l’ensemble du processus fonctionne.
• quiesce=<0|1> concerne les VM invitées spécifiques que vous souhaitez voir créées à l’aide de la méthode quiesce. Cette méthode n’est prise en charge que par le système d’exploitation Windows avec les outils invités installés. L’ensemble du travail de sauvegarde est interrompu si l’instantané de la VM invitée ne peut pas être créé via la méthode quiesce.

Il convient de noter que, puisque tous les paramètres de spécification sont eux-mêmes facultatifs, le système procédera à la sauvegarde de toutes les VM invitées disponibles si aucune entrée vm=, uuid=, exclude ou include n’a été trouvée au préalable. Il existe également un paramètre spécifique appelé abort_on_error, qui ordonne l’arrêt de l’ensemble de la tâche si une erreur est trouvée dans le processus de configuration, comme l’absence de paramètres vm=, ou de tout autre paramètre en premier lieu.

Processus de restauration

Le processus de restauration en tant qu’opération autonome poursuit deux objectifs principaux :

• La restauration vers un répertoire local à partir d’un fichier d’archive XVA ;
• La restauration vers un hyperviseur XenServer en tant que VM invitée nouvelle ou originale.

Il existe plusieurs méthodes qui peuvent être utilisées pour le processus de restauration. Par exemple, voici une méthode de restauration vers le XenServer. Elle nécessite la mise en place d’un paramètre de restauration « where=/ » dans Bacula. Dans ce cas, l’archive de la VM invitée en question sera restaurée en tant que nouvelle VM invitée via Citrix Hypervisor, ou restaurée en tant que forme originale de cette VM si l’option preserve est définie au préalable. Si vous ne définissez pas un chemin d’accès correct pour le processus de restauration, la VM invitée sera créée dans le répertoire par défaut de Citrix Hypervisor.

Il existe également la méthode de restauration vers le répertoire local, qui utilise le paramètre de restauration « where=/some/path ». Ce chemin doit représenter un emplacement spécifique sur le serveur où le module est installé, et même s’il n’existe pas, il sera créé par le plugin lui-même.

Le processus de restauration de base est relativement facile en soi, il nécessite l’exécution d’une commande spécifique, avec le paramètre « where » ajouté d’une manière ou d’une autre :

En ce qui concerne les paramètres de restauration utilisés pour inclure ou exclure des VM spécifiques, ils sont similaires à ceux utilisés dans le processus de sauvegarde. Il y a également quelques ajouts à cela :

• server : <address> est utilisé pour spécifier l’adresse API XenServer pour effectuer l’opération, et dans le cas où ce paramètre est incorrect ou absent – celui par défaut sera utilisé à la place ;
• port : <number> sert à spécifier le port de l’API XenServer à utiliser, doit être compris entre 1 et 65536 ; le paramètre invalide entraîne l’abandon du travail et l’omission de ce paramètre conduit au processus utilisant le port par défaut.