Bienvenue > Blog sur la sauvegarde et la restauration > Pourquoi sauvegarder les machines virtuelles QEMU : méthodes, configuration et meilleures pratiques
Mis à jour 21st avril 2025, Rob Morrison

Pourquoi sauvegarder les machines virtuelles QEMU ?

Les machines virtuelles sont la colonne vertébrale de presque toutes les infrastructures informatiques modernes, et les machines virtuelles basées sur QEMU sont très populaires dans les environnements virtuels. La création de sauvegardes adéquates de ces environnements virtuels n’est pas seulement une recommandation, c’est généralement une partie obligatoire de tout plan de continuité des activités et de reprise après sinistre. Des sauvegardes correctement entretenues deviennent le filet de sécurité d’une entreprise lorsque son matériel tombe en panne (et il n’existe pas de matériel infaillible).

Les environnements virtuels présentent des avantages uniques par rapport au matériel physique pour la création de sauvegardes efficaces et cohérentes. Quant à QEMU, il s’agit d’un émulateur gratuit et open source qui utilise la traduction binaire dynamique pour émuler le processeur d’un ordinateur. QEMU peut émuler diverses architectures informatiques, faire fonctionner des systèmes d’exploitation invités et même prendre en charge de nombreuses options matérielles différentes. De plus, QEMU fonctionne facilement comme backend d’émulation de périphériques ou hyperviseur pour les machines virtuelles, ce qui le rend très attrayant pour un large éventail d’utilisateurs.

Les machines virtuelles QEMU intègrent des systèmes d’exploitation personnalisés, des données d’application critiques et des configurations précieuses. La perte d’un tel environnement signifie généralement la perte d’heures ou de jours de travail de configuration, tout en risquant de perturber les opérations commerciales, le service client et, dans le pire des cas, d’entraîner des conséquences encore plus graves. Ces informations doivent donc être protégées, et les sauvegardes sont souvent considérées comme l’un des moyens les plus fiables et les plus polyvalents pour y parvenir.

La plupart des cadres réglementaires en matière de conformité exigent désormais des sauvegardes, y compris des cadres de conservation spécifiques. Ajoutez à cela le fait que les sauvegardes peuvent également protéger les informations contre les attaques de ransomware, et vous comprendrez facilement pourquoi ce sujet est si important.

L’investissement dans des stratégies de sauvegarde des VM appropriées est rentable à bien des égards : réduction des temps d’arrêt, amélioration de la continuité des activités et tranquillité d’esprit générale qui découle du fait de savoir que vos données sont récupérables après pratiquement n’importe quelle catastrophe. L’architecture ouverte de QEMU rend également les stratégies de sauvegarde plus flexibles, ce qui permet d’utiliser à la fois des approches simples basées sur des fichiers et des solutions incrémentielles complexes. Cet article explore les sauvegardes QEMU, en passant en revue différentes méthodes, processus de configuration et meilleures pratiques potentielles.

Méthodes de sauvegarde pour QEMU

Il existe plusieurs types de sauvegarde pouvant être utilisés pour protéger les machines virtuelles QEMU, chaque approche présentant ses propres avantages et inconvénients. La solution de sauvegarde et de restauration la plus efficace pour une situation spécifique dépendra des performances et des exigences de sécurité de l’entreprise, de ses politiques, de ses contraintes de stockage, entre autres facteurs, ce qui rend irréaliste l’identification d’une solution de sauvegarde qui soit meilleure dans toutes les situations.

L’article explore ensuite les principales stratégies de sauvegarde qui ont fait leurs preuves dans les environnements QEMU.

Sauvegarde complète

Les sauvegardes complètes doivent capturer toutes les informations d’un emplacement spécifique en une seule fois, c’est-à-dire l’intégralité du disque virtuel avec tous ses fichiers de configuration et autres informations associées à la machine virtuelle. En d’autres termes, une sauvegarde complète crée une réplique complète et autonome d’une machine virtuelle, ce qui la rend facilement restaurable sans nécessiter d’autre jeu de sauvegarde.

La combinaison de la simplicité et de la vitesse de récupération est sans aucun doute le plus grand avantage des sauvegardes complètes. Une sauvegarde complète élimine le besoin de rassembler plusieurs composants de sauvegarde pour restaurer les informations en cas de sinistre : il suffit de restaurer la sauvegarde complète et de poursuivre vos tâches professionnelles. Cette méthode est particulièrement utile pour protéger les machines virtuelles les plus critiques de l’environnement, où le coût des temps d’arrêt est nettement plus élevé que le coût du stockage.

Cela dit, les sauvegardes complètes nécessitent un espace de stockage et une bande passante réseau importants. Il existe également un risque que les informations soient dupliquées plusieurs fois, en raison du manque de granularité des sauvegardes complètes, ce qui les rend encore moins efficaces en termes de stockage. Ainsi, les environnements disposant d’une capacité de stockage limitée ne peuvent pas se contenter des sauvegardes complètes comme seule stratégie, et il en va de même pour les machines virtuelles généralement volumineuses.

Sauvegarde incrémentielle

Les sauvegardes incrémentielles peuvent être considérées comme un « juste milieu » entre les deux méthodes de sauvegarde. Une fois la sauvegarde complète terminée, toutes les sauvegardes incrémentielles ultérieures ne capturent que les informations qui ont été modifiées depuis la dernière sauvegarde (de tout type). De cette façon, les sauvegardes deviennent à la fois beaucoup plus efficaces en termes de stockage et exponentiellement plus rapides que les sauvegardes complètes.

L’approche de sauvegarde incrémentielle de QEMU utilise le « suivi des blocs modifiés » via des bitmaps pour surveiller les blocs qui ont été modifiés depuis la dernière sauvegarde. Ce mécanisme permet de minimiser l’impact de la sauvegarde sur les performances du système, tout en créant une chaîne de fichiers de sauvegarde gérables qui représentent l’état complet de la VM.

Cela dit, c’est lors du processus de restauration que les avantages des sauvegardes incrémentielles deviennent un peu moins impressionnants. Chaque processus de restauration nécessite le traitement de la sauvegarde complète d’origine et de chaque fichier incrémentiel dans un ordre spécifique. Il est nécessaire de gérer ces chaînes avec soin afin de s’assurer qu’aucun fichier n’est corrompu et qu’aucun lien manquant ne compromet l’ensemble de la stratégie de sauvegarde.

Les sauvegardes incrémentielles restent assez populaires dans la plupart des environnements où l’efficacité du stockage et les fenêtres de sauvegarde réduites sont prioritaires.

Sauvegarde différentielle

Les sauvegardes différentielles, quant à elles, offrent un compromis entre les méthodes de sauvegarde complète et incrémentielle. Une fois la sauvegarde complète initiale créée, chaque opération différentielle suivante capture toutes les modifications apportées depuis la sauvegarde d’origine.

Par rapport aux sauvegardes incrémentielles, les sauvegardes différentielles offrent un processus de restauration beaucoup plus simple, car seules la sauvegarde complète et la dernière sauvegarde différentielle sont nécessaires. Par conséquent, les processus de restauration à l’aide de sauvegardes différentielles sont plus rapides et plus prévisibles, contrairement au processus lent de reconstruction de longues chaînes incrémentielles. Les sauvegardes différentielles constituent un bon compromis pour les environnements de taille moyenne qui ont besoin à la fois d’une simplicité de récupération et d’une efficacité de stockage.

Le plus gros problème avec les sauvegardes différentielles est tout simplement le passage du temps. Au fur et à mesure que le temps passe depuis la dernière sauvegarde complète, chaque fichier différentiel suivant grossit, rivalisant parfois avec la taille originale d’une sauvegarde complète si trop de temps s’est écoulé. Par conséquent, les sauvegardes différentielles sont généralement plus efficaces lorsqu’il existe des sauvegardes complètes régulières qui réinitialisent la base de référence pour les sauvegardes différentielles et maintiennent l’efficacité opérationnelle.

Comment configurer la sauvegarde incrémentielle dans QEMU ?

La mise en œuvre de la sauvegarde incrémentielle dans QEMU est particulièrement intéressante, car c’est souvent la méthode privilégiée pour ce type de virtualisation. Une fois encore, une configuration et une mise en œuvre correctes nécessitent une compréhension approfondie des différents mécanismes sous-jacents, ce que cet article aborde ensuite. Ici, l’article couvre trois étapes importantes du processus : la création de l’infrastructure de sauvegarde initiale, l’utilisation de libvirt pour la gestion des sauvegardes et la mise en place de procédures cohérentes pour les opérations régulières à l’avenir.

Création de la tâche de sauvegarde initiale

La mise en place de la sauvegarde complète initiale avec suivi par bitmap est la base de toute stratégie de sauvegarde incrémentielle future dans QEMU. Il s’agit d’une étape très importante qui crée un point de référence pour toutes les sauvegardes futures.

Le processus en question n’est pas particulièrement difficile, mais il peut s’avérer complexe dans certaines situations. La première étape consiste à créer un bitmap persistant pour suivre les blocs modifiés sur un disque virtuel. Ce bitmap peut être traité comme la mémoire de QEMU, ce qui permet à QEMU de savoir quels secteurs du disque ont été modifiés depuis la dernière opération de sauvegarde.

Une commande exécutable pour activer le bitmap (dans le moniteur QEMU) devrait ressembler à ceci : block-dirty-bitmap-add drive0 backup-bitmap persistent=on

Une fois le bitmap établi, il est temps d’effectuer la sauvegarde complète initiale en tenant compte de la VM en cours d’exécution. Cette commande particulière ne doit inclure que le strict minimum de configurations : emplacement cible, format, etc.

drive-backup drive0 sync=full target=/backup/path/vm-base.qcow2 format=qcow2
Cet exemple crée un fichier de sauvegarde de base au format qcow2, qui sert de point de départ à la chaîne incrémentielle. Il est primordial de stocker cette image de base dans un environnement sûr, car sa corruption peut compromettre toutes les sauvegardes incrémentielles qui l’utilisent comme point de départ.

Utilisation de Libvirt pour gérer les opérations de sauvegarde

Libvirt est un ensemble open source de bibliothèques et de logiciels qui permet la gestion centralisée de différents hyperviseurs, notamment QEMU, Xen, KVM, LXC, VMware et bien d’autres. Libvert se compose d’un démon, d’une API et d’utilitaires de ligne de commande pour faire fonctionner cette API.

Libvirt contribue à améliorer la gestion des sauvegardes QEMU en utilisant une couche API cohérente qui résume les nombreuses complexités de l’environnement. Libvirt est une boîte à outils puissante qui peut améliorer les tâches de l’hyperviseur en fournissant des capacités d’automatisation et une structure flexible, qui doivent autrement être effectuées manuellement à l’aide de séquences de commandes.

La première chose à faire après avoir tenté de configurer les sauvegardes libvirt dans QEMU est de vérifier que l’installation actuelle prend en charge les fonctionnalités de sauvegarde incrémentielle (toutes les versions supérieures à 6.0.0 devraient la prendre en charge). La commande correcte pour vérifier la version de libvirt est la suivante :

$ virsh –version
Ensuite, configurez le XML du domaine pour inclure les définitions de sauvegarde nécessaires. Le fichier XML du domaine actuel peut être consulté à l’aide de la commande suivante :
$ virsh dumpxml vm_name > vm_config.xml
Une fois le fichier extrait, modifiez la configuration pour inclure des éléments de sauvegarde comme suit :
<domain>

<backup>
<disks>
<disk name=’vda’ backup=’yes’ type=’file’>
<target file=’/backup/path/incremental1.qcow2’/>
</disk>
</disks>
</backup>

</domain>
Une fois la configuration modifiée, l’opération de sauvegarde peut être exécutée à l’aide de la commande suivante :
$ virsh backup-begin vm_name –backupxml vm_config.xml
La capacité de la fonctionnalité de point de contrôle de Libvirt à gérer la coordination entre plusieurs disques, si nécessaire, peut s’avérer extrêmement précieuse pour les utilisateurs.
$ virsh checkpoint-create vm_name checkpoint_config.xml

Guide étape par étape pour effectuer une nouvelle sauvegarde incrémentielle

Une fois tous les processus de configuration de base terminés, des sauvegardes incrémentielles régulières peuvent être exécutées à l’aide de la séquence de commandes suivante :

  1. Pour geler le système de fichiers invité (si l’agent invité est déjà configuré) :
$ virsh qemu-agent-command your_vm_name ‘{« execute »: »guest-fsfreeze-freeze »}’
  1. Pour créer une nouvelle sauvegarde incrémentielle tout en spécifiant le bitmap de suivi :
drive-backup drive0 sync=incremental bitmap=backup-bitmap \
target=/path/to/backup/vm-incremental-$(date +%Y%m%d).qcow2 format=qcow2
  1. Pour débloquer le système de fichiers invité afin de reprendre les opérations normales :
$ virsh qemu-agent-command vm_name ‘{« execute »: »guest-fsfreeze-thaw »}’
  1. Pour réinitialiser le bitmap de suivi des modifications afin de préparer le cycle de sauvegarde suivant :
block-dirty-bitmap-clear drive0 backup-bitmap
  1. Pour vérifier la fin de la sauvegarde et la documentation :
$ qemu-img info /backup/path/vm-incremental-$(date +%Y%m%d).qcow2
  1. Pour tester régulièrement l’intégrité de la sauvegarde afin de garantir la récupérabilité :
$ qemu-img check /backup/path/vm-incremental-$(date +%Y%m%d).qcow2

Ce workflow particulier parvient à équilibrer efficacité et rigueur, en minimisant l’impact sur les charges de travail en cours et en garantissant également une chaîne de sauvegarde fiable pour les scénarios de reprise après sinistre potentiels.

Que sont les commandes QMP pour la sauvegarde incrémentielle ?

Le protocole QEMU Machine Protocol, souvent appelé QMP, offre une interface JSON pour la surveillance et le contrôle par programmation de diverses instances QEMU. En ce qui concerne plus particulièrement les opérations de sauvegarde, QMP permet un contrôle précis, particulièrement utile pour l’automatisation ou l’intégration avec des solutions de sauvegarde personnalisées. Les commandes suivantes peuvent être exécutées soit directement à l’aide du moniteur QEMU, soit à l’aide de scripts pour créer des opérations planifiées :

Introduction aux commandes QMP de base

Les commandes QMP utilisent une structure JSON cohérente pour faciliter des tâches telles que la création de scripts et l’automatisation. La création de scripts et l’automatisation permettent un contrôle précis des mécanismes internes de QEMU sans accès direct à l’interface console d’un hyperviseur.

Pour passer en mode QMP pendant l’exécution de QEMU, connectez-vous à la socket du moniteur QEMU et initialisez la connexion de la manière suivante :

$ socat UNIX:/path/to/qemu-monitor-socket –
{« execute »: « qmp_capabilities »}

Voici quelques-unes des commandes les plus utiles pour les opérations de sauvegarde :

  • block-dirty-bitmap-add pour le suivi des modifications ;
  • drive-backup pour l’exécution des sauvegardes ; et
  • transaction pour diverses tâches de regroupement, etc.

Chacune de ces commandes accepte également un certain nombre de paramètres spécifiques au format JSON :

{« execute »: « block-dirty-bitmap-add »,
« arguments »: {« node »: « drive0 », « name »: « backup-bitmap », « persistent »: true}}
Les réponses structurées de QMP sont parfaites pour analyser les ressources programmatiques. Chaque commande produit un objet JSON qui représente soit la réussite, soit l’échec, ainsi qu’une multitude de détails pertinents. Une telle approche structurée rend la gestion des erreurs des scripts de sauvegarde automatisés beaucoup plus efficace, ce qui est une fonctionnalité inestimable dans tout environnement de production.

Comment créer une nouvelle sauvegarde incrémentielle à l’aide de QMP

La création d’une sauvegarde incrémentielle à l’aide de QMP est une séquence d’opérations logiques qui capture uniquement les blocs modifiés tout en conservant la cohérence des données. Elle utilise également le suivi par bitmap pour minimiser la durée et la taille de la sauvegarde, de la même manière que dans les différents exemples ci-dessus.

Si un bitmap de suivi n’existe pas, il doit être créé une seule fois avant la sauvegarde complète. Voici comment procéder :

{« execute »: « block-dirty-bitmap-add »,
« arguments »: {« node »: « drive0 », « name »: « backup-bitmap », « persistent »: true}}
Une fois le bitmap établi, la commande drive-backup doit être utilisée pour exécuter une sauvegarde complète à l’aide des paramètres nécessaires :
{« execute »: « drive-backup »,
« arguments »: {« device »: « drive0 », « sync »: « full »,
« target »: « /path/to/vm-base.qcow2 », « format »: « qcow2 »}}
Toutes les sauvegardes incrémentielles suivantes modifient légèrement cette séquence, en remplaçant full par incremental dans les types de sauvegarde et en référençant le bitmap de suivi créé ci-dessus afin de ne capturer que les blocs modifiés :
{« execute »: « drive-backup »,
« arguments »: {« device »: « drive0 », « sync »: « incremental », « bitmap »: « backup-bitmap »,
« target »: « /path/to/vm-incr-20250407.qcow2 », « format »: « qcow2 »}}

Comprendre les images de sauvegarde et les bitmaps

La relation entre les images de sauvegarde et les bitmaps sales constitue la base technique des sauvegardes incrémentielles efficaces dans QEMU. Seule une bonne compréhension de ces relations permet de maintenir des chaînes de sauvegarde propres.

Les images de sauvegarde créent des relations parent-enfant entre les fichiers qcow2 afin que chaque sauvegarde incrémentielle puisse référencer son prédécesseur. Interrogez la chaîne de sauvegarde de n’importe quelle image qcow2 à l’aide de la commande QMP suivante :

{« execute »: « query-block »,
« arguments »: {« query-backing-chain »: true}}

La même commande peut également être utilisée pour afficher les bitmaps existants sur un lecteur spécifique en modifiant l’un des arguments :
{« execute »: « query-block »,
« arguments »: {« filter-node-name »: « drive0 »}}
La cohérence des bitmaps doit être soigneusement maintenue tout au long des opérations de sauvegarde afin de créer des chaînes incrémentielles fiables. Une fois la sauvegarde incrémentielle terminée, il est recommandé d’effacer également le bitmap afin de commencer à suivre toutes les modifications à partir de zéro pour la prochaine opération potentielle :
{« execute »: « block-dirty-bitmap-clear »,
« arguments »: {« node »: « drive0 », « name »: « backup-bitmap »}}

Une opération de réinitialisation comme celle-ci marque la fin d’un cycle de sauvegarde unique et prépare également le système à l’exécution du cycle suivant.

Problèmes courants et dépannage des sauvegardes incrémentielles QEMU

Même la meilleure planification au monde ne peut empêcher les opérations de sauvegarde QEMU de rencontrer des obstacles ou des problèmes. Savoir comment les diagnostiquer et les résoudre efficacement est une connaissance cruciale qui peut faire la différence entre des inconvénients mineurs et des pertes de données importantes. Cette section aborde certains des défis les plus courants auxquels les administrateurs sont confrontés en matière de solutions de sauvegarde incrémentielle.

« Bitmap introuvable »

Les erreurs « Bitmap introuvable » sont généralement dues à des problèmes de persistance des bitmaps. Pour que le suivi incrémentiel soit cohérent avec QEMU, les bitmaps doivent persister après le redémarrage des machines virtuelles. Le drapeau persistent=on doit être utilisé lors de la création de chaque nouveau bitmap, car il n’existe aucun moyen de modifier le paramètre de persistance d’un bitmap existant autre que de le recréer à partir de zéro.

« Permission refusée »

Les erreurs d’autorisation sont assez courantes dans les opérations de sauvegarde, en particulier dans les environnements soumis à des règles de sécurité complexes. Il existe une commande de test qui peut être lancée pour vérifier que le processus QEMU dispose des autorisations nécessaires pour écrire dans votre destination de sauvegarde :

$ sudo -u libvirt-qemu touch /path/to/backup/test-write.tmp
$ rm /path/to/backup/test-write.tmp
Si ce test échoue, la seule solution consiste à ajuster manuellement les autorisations ou la propriété d’un répertoire de sauvegarde.

« Le périphérique est verrouillé »

Si certaines opérations ont des verrous exclusifs sur le périphérique cible, les opérations de sauvegarde peuvent échouer avec le message « Le périphérique est verrouillé ». Ces verrous peuvent se produire pendant des instantanés ou des tâches de sauvegarde simultanées, et la seule façon de les éviter est de répertorier au préalable les tâches de sauvegarde actives afin de pouvoir trouver manuellement les conflits potentiels :

block-job-list

Il est également possible d’annuler certaines opérations, le cas échéant, à l’aide de la commande suivante :
block-job-cancel job-id

Chaînes de sauvegarde corrompues

La corruption de la chaîne de sauvegarde est particulièrement problématique dans ce contexte, car elle rend immédiatement inutilisables toutes les sauvegardes incrémentielles suivantes. La meilleure approche de récupération dans de telles situations consiste à créer une nouvelle sauvegarde complète et à établir une nouvelle chaîne pour repartir de zéro :

drive-backup drive0 sync=full target=/path/to/backup/new-base.qcow2 format=qcow2

États incohérents des applications

L’incohérence peut perturber le processus de sauvegarde et entraîner des sauvegardes incomplètes ou endommagées. Dans ce cas, la résolution exacte dépend de la nature du problème, il n’existe donc pas de solution unique pour tous les problèmes.

Par exemple, si une application effectuait des opérations d’écriture pendant la sauvegarde, cela peut entraîner des sauvegardes avec des données partiellement écrites. Cela ne peut être résolu qu’en arrêtant toutes les machines virtuelles associées avant d’effectuer les opérations de sauvegarde, puis en les dégelant ensuite à l’aide des commandes suivantes :

$ virsh qemu-agent-command vm-name ‘{« execute »: »guest-fsfreeze-freeze »}’
# Effectuer les opérations de sauvegarde
$ virsh qemu-agent-command vm-name ‘{« execute »: »guest-fsfreeze-thaw »}’

Épuisement de l’espace disque

L’épuisement de l’espace disque peut interrompre les opérations de sauvegarde, laissant derrière lui des fichiers de sauvegarde incomplets. Ces fichiers ne font que consommer de l’espace de stockage : ils n’ont aucune valeur de récupération sous leur forme incomplète. La surveillance de l’espace est une autre couche de commandes qui doit être implémentée dans les scripts de sauvegarde afin d’empêcher le démarrage de toute opération lorsque l’espace disponible peut tomber en dessous d’un certain seuil.

$ df -h /backup/path/ | awk ‘NR==2 {print $5}’ | sed ‘s/%//’

Il convient d’envisager la mise en place de processus de nettoyage réguliers pour supprimer les fichiers de sauvegarde partiels.

« Image not in qcow2 format »

Les opérations de sauvegarde peuvent échouer avec l’erreur « Image not in qcow2 format« , même lorsque le format correct est spécifié au préalable. Ce type de problème survient souvent lors de tentatives de sauvegardes incrémentielles lorsque les images de base sont stockées dans un format incompatible.

Pour résoudre ce problème, vérifiez d’abord le format de l’image de base :

$ qemu-img info /backup/path/base-image.qcow2

Une fois le format vérifié, l’image en question peut être convertie en qcow2, tout en démarrant une nouvelle chaîne de sauvegarde, à l’aide de la commande suivante :
$ qemu-img convert -O qcow2 original-image.raw /backup/path/converted-base.qcow2
Un dépannage efficace commence toujours par une journalisation complexe. Une journalisation détaillée des opérations de sauvegarde est essentielle pour capturer des informations détaillées lorsque diverses erreurs ou problèmes apparaissent :
$ QEMU_MONITOR_DEBUG=1 virsh backup-begin vm-name backup-xml.xml
Ces journaux s’avèrent inestimables pour diagnostiquer des problèmes complexes qui seraient pratiquement insolubles autrement.

Méthodes de sauvegarde pour les machines virtuelles QEMU en cours d’exécution

Il existe plusieurs différences notables entre les deux approches de gestion des sauvegardes QEMU présentées ici.

La première consiste à utiliser les commandes du moniteur QEMU : elles sont exécutées directement via la console du moniteur QEMU à l’aide d’une syntaxe textuelle et sont généralement utilisées pour effectuer diverses tâches manuellement. S’il est vrai que libvirt offre certaines fonctionnalités pour faciliter l’automatisation, son principe de base reste plus proche des commandes directes du moniteur QEMU.

La seconde utilise QMP, ou QEMU Machine Protocol, un système conçu pour les interactions programmatiques accessible via une connexion socket. Il est parfait pour les scripts, l’automatisation et le séquençage des sauvegardes grâce à ses commandes et réponses au format JSON.

Leur fonctionnalité est essentiellement la même, il s’agit simplement d’interfaces différentes pour accéder aux mêmes fonctionnalités de QEMU.

Ces deux approches offrent plusieurs façons différentes de créer une sauvegarde d’une VM en cours d’exécution dans QEMU. Certaines de ces possibilités ont déjà été explorées, telles que le suivi des blocs sales, les capacités de gel/dégel de l’agent invité de QEMU et la capacité de point de contrôle de libvirt.

Une alternative qui n’a pas encore été mentionnée est la fonctionnalité external snapshot. Elle est souvent considérée comme l’une des approches les plus simples pour travailler avec des VM en cours d’exécution, car elle consiste à créer un nouveau fichier de superposition vers lequel toutes les opérations d’écriture sont redirigées, tandis que l’image disque d’origine est conservée telle quelle pour le processus de sauvegarde. Une commande permettant d’utiliser cette méthode se présente comme suit :

$ virsh snapshot-create-as –domain vm-name snap1 –diskspec vda,file=/path/to/overlay.qcow2 –disk-only
Une fois le processus de sauvegarde terminé, il est important de valider toutes les modifications du fichier de superposition dans l’image de base d’une manière spécifique :
$ virsh blockcommit vm-name vda –active –pivot
Il convient également de noter que certaines solutions de sauvegarde tierces offrent des capacités d’intégration avec QEMU qui fournissent une variété de fonctionnalités supplémentaires : gestion centralisée, compression, déduplication, prise en charge de la sauvegarde des machines virtuelles actives, etc. Elles exploitent l’API de QEMU tout en ajoutant leurs propres couches d’orchestration et leurs propres réglages d’optimisation du stockage. Pour clarifier le sujet, nous pouvons prendre une de ces solutions et explorer ses capacités plus en détail, ce que fait précisément l’article ci-dessous avec Bacula Enterprise.

Toutes ces méthodes de sauvegarde ont leurs avantages distincts et leurs contextes de production dans lesquels elles surpassent les autres, par exemple :

  • Suivi des blocs sales avec sauvegardes incrémentielles : l’une des approches les plus équilibrées, offrant un impact minimal sur les performances et une grande efficacité ; une excellente option pour les environnements de production avec des fenêtres de sauvegarde limitées et des machines virtuelles raisonnablement volumineuses.
  • Intégration d’agents invités (gel/dégel) : option courante pour les applications à forte transaction et les serveurs de bases de données qui exigent une cohérence totale des données, même au prix de brèves fenêtres d’indisponibilité pendant les sauvegardes.
  • Capacités de point de contrôle : offrent la récupération la plus complète, mais au prix d’une utilisation élevée des ressources, ce qui en fait l’option privilégiée dans les environnements de développement et les systèmes critiques où la préservation de l’état de l’application justifie une surcharge supplémentaire.
  • Instantanés externes : excellents dans les environnements qui nécessitent des sauvegardes avec peu ou pas de configuration, ce qui les rend parfaits pour les machines virtuelles petites et moyennes avec une tolérance suffisante pour de brefs ralentissements.
  • Solutions de sauvegarde tierces : offrent la meilleure expérience aux entreprises disposant d’un grand nombre de machines virtuelles et d’hôtes, en mettant l’accent sur la gestion centralisée et les fonctionnalités avancées qui justifient leurs coûts de licence élevés.

API de sauvegarde QEMU et outils d’intégration

Le riche écosystème d’API de QEMU offre aux développeurs et aux administrateurs un accès programmatique approfondi à des capacités de virtualisation polyvalentes. Ces API constituent la base des opérations de sauvegarde, fournissant des interfaces cohérentes et abstraisant les complexités de la gestion de plusieurs environnements de machines virtuelles.

L’interface Block Device est au cœur des capacités de sauvegarde de QEMU. Elle permet d’effectuer des opérations de gestion des disques virtuels, notamment, mais sans s’y limiter, les capacités de sauvegarde et de snapshot expliquées ci-dessus. Cette interface peut prendre en charge des opérations telles que la gestion des bitmaps, blockdev-backup et drive-backup via QMP et QEMU Monitor. Ces fonctions de bas niveau sont également parfaites pour les développeurs qui créent des solutions de sauvegarde personnalisées, offrant un contrôle granulaire sur pratiquement tous les aspects du processus de sauvegarde.

L’API libvirt est une autre option populaire dans ce contexte, qui encapsule les interfaces natives de QEMU dans une couche d’abstraction standardisée pouvant même fonctionner sur différents hyperviseurs. Comme mentionné précédemment, libvirt aide à simplifier les opérations de sauvegarde grâce à des fonctions de haut niveau capables de gérer automatiquement divers détails sous-jacents. Par exemple, la fonction virDomainBackupBegin() peut gérer tous les aspects du lancement d’une sauvegarde incrémentielle, du suivi des bitmaps aux instantanés temporaires.

Quant aux développeurs Python, les liaisons libvirt-python peuvent être utilisées comme point d’entrée relativement pratique vers l’ensemble d’outils de sauvegarde de QEMU. Les liaisons fournissent l’API libvirt complète dans une syntaxe Python, ce qui rend les scripts d’automatisation beaucoup plus lisibles et faciles à maintenir. Voici à quoi ressemblerait un script de sauvegarde simple en Python :

import libvirt
conn = libvirt.open(‘qemu:///system’)
dom = conn.lookupByName(‘vm-name’)
dom.backupBegin(backup_xml, None)
La nature standardisée de ces API crée un riche écosystème de solutions de sauvegarde tierces qui viennent étendre les capacités existantes de QEMU. Il existe de nombreux outils différents qui peuvent tirer parti de ces API pour créer des expériences de sauvegarde riches en fonctionnalités, tout en simplifiant bon nombre des complexités techniques abordées dans cet article. La suite de cet article explore les fonctionnalités essentielles des solutions de sauvegarde QEMU tierces, en utilisant Bacula Enterprise pour illustrer comment une solution de sauvegarde peut fonctionner avec l’ensemble des fonctionnalités d’origine de QEMU.

Fonctionnalités essentielles d’une solution de sauvegarde QEMU

Certaines fonctionnalités clés distinguent les solutions de sauvegarde robustes des approches basiques des processus de sauvegarde. Les fonctionnalités essentielles telles que celles mentionnées ci-dessous doivent garantir qu’une stratégie de sauvegarde QEMU reste fiable, efficace et récupérable dans divers environnements de virtualisation.

Les mécanismes de cohérence des données sont la fonctionnalité la plus critique de toute solution de sauvegarde compétente dans ce contexte. Une solution de sauvegarde doit s’intégrer facilement à l’API Guest Agent de QEMU ou proposer ses propres plugins adaptés aux applications afin de garantir la cohérence de la base de données. La capacité à coordonner les applications en cours d’exécution peut aider à créer des sauvegardes dans un état propre et récupérable, sans aucune corruption en cours de transaction. Des solutions avancées pour les cas d’utilisation spécifiques au stockage qui vont au-delà des cycles de gel-dégel doivent également être envisagées, le cas échéant, afin de permettre la gestion séparée des états de transaction d’applications spécifiques.

Une gestion efficace du stockage est un autre point important pour les solutions de sauvegarde complètes, avec des fonctionnalités courantes telles que la déduplication, la compression, la conservation automatisée, etc. Les approches incrémentielles permanentes offrent des fenêtres de sauvegarde et une consommation de stockage minimales grâce à un suivi intelligent des modifications. Dans ce contexte, une vérification automatisée régulière est pratiquement obligatoire, afin de tester l’intégrité et la récupérabilité des sauvegardes dans la mesure du possible, et de garantir qu’elles sont toujours viables et complètes.

L’orchestration et la planification sont toutes deux extrêmement importantes pour les environnements plus complexes, car elles transforment les procédures de sauvegarde manuelles en processus fiables et automatisés sans qu’il soit nécessaire de créer des scripts complexes. Une gestion intelligente des ressources, la gestion des dépendances et des options de planification flexibles sont autant de fonctionnalités attendues dans ce domaine. Au-delà de ces fonctionnalités de base, toute solution de sauvegarde compétente pour QEMU doit inclure des mécanismes complets de reporting et d’alerte, ainsi qu’une intégration avec les systèmes de surveillance existants et la prise en charge RBAC pour un meilleur contrôle des accès.

Toutes ces fonctionnalités deviennent de plus en plus importantes à mesure que l’infrastructure virtuelle des entreprises gagne en taille et en complexité, transformant la sauvegarde d’un processus technique en une application métier avec des exigences de gouvernance spécifiques et des responsabilités bien définies.

Comment sauvegarder QEMU avec Bacula ?

Bacula Enterprise offre une prise en charge étendue des environnements QEMU grâce à son module de virtualisation, entre autres fonctionnalités. Bacula combine la nature open source de l’environnement avec une gestion centralisée, un support premium et un contrôle fin de pratiquement tous les processus. Cette combinaison incroyable de paramètres en fait une solution privilégiée pour les grandes entreprises ayant des besoins diversifiés en matière d’infrastructure virtuelle.

La configuration de Bacula pour les sauvegardes QEMU commence par l’installation du démon Bacula File Daemon sur les hôtes hyperviseurs. Le démon doit être configuré pour accéder à vos instances QEMU à l’aide de libvirt, ce qui permet d’effectuer des sauvegardes complètes et incrémentielles sans risque de corruption des données.

Une configuration de base pour ces sauvegardes est stockée dans le fichier de configuration de Bacula Director, où les utilisateurs peuvent définir des tâches de sauvegarde pour cibler des machines virtuelles spécifiques :

Job {
Name = « QEMU-VM-Backup »
JobDefs = « DefaultJob »
Client = qemu-host-fd
Pool = VMPool
FileSet = « QEMU-VMs »
}
FileSet {
Nom = « QEMU-VMs »
Inclure {
Options {
signature = MD5
compression = GZIP
}
Plugin = « qemu: VM=vm-name »
}
}
Une configuration comme celle-ci exploite le plugin QEMU de Bacula pour gérer automatiquement toutes les complexités et nuances de ce processus de sauvegarde (y compris le suivi des bitmaps).

L’une des fonctionnalités les plus puissantes de Bacula est son approche basée sur un catalogue pour les capacités de restauration multi-VM. Bacula peut conserver des métadonnées détaillées de chaque sauvegarde et toutes les relations entre elles si nécessaire. De cette façon, une restauration précise à un moment donné devient possible sans avoir à suivre manuellement les chaînes de sauvegarde ou les dépendances de restauration.

Pour la reprise après sinistre, Bacula utilise ses capacités de restauration à froid pour restaurer l’intégralité des hyperviseurs, ainsi que toutes leurs configurations de VM et images disque. Les pistes d’audit complètes et les mesures de conservation de Bacula sont particulièrement utiles dans les entreprises soumises à des exigences de conformité strictes.

Les nombreuses fonctionnalités d’entreprise de Bacula, associées à son architecture ouverte, en font une option intéressante pour les entreprises qui ont besoin de capacités de sauvegarde QEMU robustes, capables d’évoluer de déploiements sur un seul serveur à de vastes environnements multi-datacenters.

Foire aux questions

Quelles sont les différentes méthodes de sauvegarde d’une machine virtuelle QEMU ?

Les machines virtuelles QEMU disposent de plusieurs méthodes pour créer des sauvegardes, notamment les sauvegardes complètes, les sauvegardes incrémentielles, les sauvegardes différentielles et les instantanés externes.

  • Les sauvegardes complètes capturent l’intégralité de la VM, mais nécessitent un espace de stockage considérable.
  • Les sauvegardes incrémentielles utilisent le suivi des blocs modifiés pour surveiller efficacement les blocs modifiés, mais sont difficiles à restaurer.
  • Les sauvegardes différentielles constituent un compromis entre les deux, mais leur champ d’application n’est pas particulièrement universel.
  • Les instantanés externes redirigent temporairement les opérations d’écriture vers des fichiers de superposition pendant la sauvegarde de l’image de base.

Est-il possible de sauvegarder une machine virtuelle QEMU en cours d’exécution sans interruption de service ?

Oui, QEMU prend en charge les sauvegardes en direct des machines virtuelles en cours d’exécution à l’aide de ses propres mécanismes, tels que le suivi des blocs modifiés ou les instantanés externes. Pour une cohérence optimale, les administrateurs utilisent souvent des agents invités pour geler brièvement le système de fichiers lors des sauvegardes critiques, ce qui garantit l’intégrité des données des applications, mais rend ces sauvegardes inacceptables pour certains types d’entreprises.

Quel est le rôle de la fonctionnalité d’instantané QEMU dans les solutions de sauvegarde ?

Les instantanés QEMU créent des captures ponctuelles de l’état actuel de la machine virtuelle qui servent de base à différentes stratégies de sauvegarde. L’état des instantanés internes est stocké dans le fichier d’origine, tandis que les instantanés externes redirigent les opérations d’écriture vers des fichiers superposés distincts. Les instantanés permettent également d’activer diverses fonctionnalités utiles, telles que la restauration, le clonage, la migration, etc.

L’utilisation d’une solution de sauvegarde et de restauration hautement sécurisée pour protéger les environnements QEMU offre généralement une protection centralisée de l’ensemble de l’environnement informatique d’une organisation, ce qui est très avantageux. Elle apporte également des fonctionnalités supplémentaires en matière de surveillance, de reporting, de conformité, de sécurité et de commodité, souvent nécessaires pour les moyennes et grandes entreprises. Nous espérons que ces informations vous ont été utiles. Pour en savoir plus, rendez-vous sur www.baculasystems.com.

À propos de l’auteur
Rob Morrison
Rob Morrison est le directeur marketing de Bacula Systems. Il a commencé sa carrière dans le marketing informatique chez Silicon Graphics en Suisse, où il a obtenu de bons résultats dans divers rôles de gestion du marketing pendant près de 10 ans. Au cours des 10 années suivantes, Rob a également occupé divers postes de gestion du marketing chez JBoss, Red Hat et Pentaho, assurant la croissance des parts de marché de ces sociétés bien connues. Il est diplômé de l'université de Plymouth, titulaire d'un diplôme spécialisé en médias et communications numériques, et a suivi un programme d'études à l'étranger.
Laissez un commentaire

Votre adresse email ne sera pas publiée. Les champs requis sont indiqués *