Snapshots, clones et backups KVM : comprendre les différences

Les snapshots ne sont pas des sauvegardes. C'est l'erreur la plus courante avec KVM/libvirt. Ce guide vous explique la différence, quand utiliser chaque technique, et comment protéger vraiment vos VMs.

Ce que vous allez apprendre

• Créer et gérer des snapshots pour tester sans risque
• Cloner une VM pour la dupliquer proprement
• Faire des backups indépendants et restaurables
• Éviter les pièges de performance et de perte de données

Prérequis

Les manipulations qui suivent s'exécutent sur une VM réelle et certaines sont destructrices : menez-les sur une machine de test, jamais sur une VM de production. Trois acquis sont supposés :

• KVM/libvirt installé (guide installation)
• Une VM existante (créer une VM)
• Connaître les commandes virsh de base (guide virsh)

Les 3 techniques : comprendre les différences

Le critère qui sépare les trois techniques tient en un mot : l'indépendance. Un snapshot ne survit pas à la disparition du disque d'origine, alors qu'un clone et un backup sont des copies autonomes. Lisez donc la colonne « Indépendant » avant la colonne « Usage » : c'est elle qui décide si la technique protège ou non vos données.

Technique	Ce que c'est	Indépendant ?	Usage
Snapshot	Photo de l'état à un instant T	Non	Test rapide, rollback
Clone	Copie complète de la VM	Oui	Dupliquer un template
Backup	Export de la config + copie du disque	Oui	Sauvegarde, reprise après sinistre

Glissez pour voir

Pourquoi cette distinction est cruciale

Le piège classique : un admin crée un snapshot avant une mise à jour, pensant être protégé. La mise à jour échoue, il veut restaurer... mais le disque original est corrompu. Le snapshot dépend du disque original, les deux sont perdus.

La règle d'or : un snapshot protège contre les erreurs logiques (mauvaise config, update raté), pas contre les pannes matérielles ou la corruption.

Partie 1 : Les snapshots libvirt

Qu'est-ce qu'un snapshot ?

Un snapshot capture l'état d'une VM à un instant T. Avec QCOW2, libvirt utilise une technique appelée copy-on-write :

1. Le disque original est gelé en lecture seule
2. Les nouvelles écritures partent dans un fichier delta
3. Revenir en arrière consiste à supprimer ce delta

Avantage : création quasi-instantanée, peu d'espace disque. Inconvénient : dépendance au fichier original, performance dégradée si trop de snapshots.

Créer un snapshot

La création d'un snapshot est l'opération la moins risquée du guide : elle n'écrase rien et prend moins d'une seconde. L'enjeu réel est le nom donné au point de retour, car c'est lui que vous taperez sous pression, six semaines plus tard, quand une mise à jour aura mal tourné. La description est facultative, elle se relit dans le XML rendu par snapshot-dumpxml.

1. Vérifier l'état de la VM

   virsh domstate ma-vm

   Un snapshot peut être créé sur une VM en cours d'exécution ou arrêtée.

2. Créer le snapshot

   virsh snapshot-create-as ma-vm \
     --name "avant-upgrade" \
     --description "État stable avant mise à jour kernel"

   Sortie attendue :

   Domain snapshot avant-upgrade created

3. Vérifier la création

   virsh snapshot-list ma-vm

   Sortie attendue :

    Name           Creation Time               State
   ------------------------------------------------------
    avant-upgrade  2026-01-31 10:15:30 +0100   running

Bonnes pratiques de nommage

Utilisez des noms explicites, qui portent la date ou le contexte de création :

• avant-upgrade-kernel-6.8
• 2026-01-31-stable
• pre-migration-db

Types de snapshots

libvirt distingue deux types de snapshots, et la différence porte sur ce qui est capturé autant que sur l'endroit où le delta est écrit. Un snapshot interne range tout dans le fichier QCOW2 existant ; un snapshot externe crée un nouveau fichier. Les deux fonctionnent sur une VM allumée, mais ils ne se gèrent pas de la même façon.

Type	Ce qu'il capture	VM en cours ?	Usage
Interne	Disque + RAM (état complet)	Oui	Rollback rapide
Externe	Disque uniquement	Oui	Backup avec delta externe

Glissez pour voir

Par défaut, snapshot-create-as crée un snapshot interne si la VM tourne.

Pour créer un snapshot disque uniquement (externe) :

virsh snapshot-create-as ma-vm \
  --name "disk-only-snap" \
  --disk-only \
  --atomic

Snapshots externes

Les snapshots externes créent un nouveau fichier QCOW2 qui devient le disque actif. Le fichier original devient le backing file, en lecture seule. La technique est puissante, c'est elle qui rend possible la sauvegarde à chaud, mais elle laisse une chaîne de fichiers à recoller ensuite.

Lister et inspecter les snapshots

Trois commandes se partagent l'inspection, et elles ne répondent pas à la même question. snapshot-list dit ce qui existe, snapshot-info dit où en est un snapshot précis dans l'arbre, et snapshot-dumpxml sort la définition complète. Le champ Location d'un snapshot-info est celui qu'on regarde en premier : il vaut internal ou external, et cela change la façon de le supprimer.

Lister tous les snapshots d'une VM :

virsh snapshot-list ma-vm

Voir l'arborescence (si plusieurs snapshots) :

virsh snapshot-list ma-vm --tree

Sortie exemple :

avant-upgrade
  |
  +- test-nginx
  |
  +- test-postgres

Obtenir les détails d'un snapshot :

virsh snapshot-info ma-vm --snapshotname avant-upgrade

Sortie attendue :

Name:           avant-upgrade
Domain:         ma-vm
Current:        yes
State:          running
Location:       internal
Parent:         -
Children:       2
Descendants:    2
Metadata:       yes

Exporter la configuration XML du snapshot :

virsh snapshot-dumpxml ma-vm --snapshotname avant-upgrade

Revenir à un snapshot (revert)

C'est l'opération la plus importante : annuler les changements et revenir à l'état sauvegardé.

1. Vérifier le snapshot actuel

   virsh snapshot-current ma-vm --name

2. Revenir au snapshot

   virsh snapshot-revert ma-vm --snapshotname avant-upgrade

   Impact du revert

   Cette commande arrête la VM si elle tourne, sauf si le snapshot inclut la RAM. Elle restaure ensuite l'état du disque et perd définitivement toutes les modifications faites après la prise du snapshot.

3. Forcer le redémarrage après revert

   Si vous voulez que la VM redémarre immédiatement :

   virsh snapshot-revert ma-vm --snapshotname avant-upgrade --running

Supprimer un snapshot

Une fois que vous n'avez plus besoin d'un snapshot, supprimez-le pour libérer l'espace et améliorer les performances :

virsh snapshot-delete ma-vm --snapshotname avant-upgrade

Supprimer un snapshot et tous ses enfants :

virsh snapshot-delete ma-vm --snapshotname avant-upgrade --children

Ne pas empiler les snapshots

Chaque snapshot ajoute une couche de lecture supplémentaire, et l'idée répandue est qu'empiler les couches effondre les performances. Mesuré sur une chaîne de 1 à 10 overlays au-dessus d'une base de 1 Gio, avec qemu-img bench et le cache vidé entre chaque passe, ce n'est pas ce qui se produit : les écarts vont de +4 % à +12 % en lecture comme en écriture, sans croître avec la profondeur. C'est du bruit de mesure, pas une dégradation. La raison tient à la structure du format : les tables de correspondance de chaque couche sont en mémoire, et descendre d'un niveau est une recherche, pas une entrée-sortie de plus.

Le vrai coût d'une chaîne longue est ailleurs, et il est bien réel : l'espace que personne ne récupère, la complexité de savoir quelle couche porte quoi, et le risque de manipulation au moment de consolider. La règle de conduite ne change donc pas : créez un snapshot, testez, puis supprimez-le ou consolidez la chaîne. Elle se justifie par l'hygiène, pas par un seuil de performance.

Le piège des snapshots QCOW2 : la chaîne de dépendances

Le schéma montre pourquoi un empilement de snapshots coûte cher en entrées/sorties : chaque fichier ne contient que les blocs modifiés depuis le précédent, donc une lecture peut traverser toute la chaîne avant de trouver sa donnée.

Pour lire un bloc de données, QEMU doit :

1. Chercher dans snap2, la couche active
2. Si le bloc est absent, chercher dans snap1
3. Si le bloc est encore absent, lire dans vm.qcow2

Plus la chaîne est longue, plus les I/O sont lents.

Fusionner les snapshots (blockcommit)

Recoller la chaîne s'appelle un commit : les blocs des couches supérieures sont réécrits dans le disque de base, et la VM finit par ne plus lire qu'un seul fichier. L'option --pivot implique --active, c'est-à-dire un commit en deux temps de la couche active, qui fait basculer la machine sur le disque de base une fois la synchronisation terminée. Cette forme s'exécute donc sur une VM en cours d'exécution.

# Fusionner la couche active dans le disque de base (VM en cours d'exécution)
virsh blockcommit ma-vm vda --active --pivot

Opération risquée

Le blockcommit réécrit la structure des disques pendant que la VM tourne. Faites un backup avant, et vérifiez ensuite avec virsh domblklist que le domaine pointe bien sur le fichier de base attendu.

Partie 2 : Cloner une VM

Le clonage crée une copie complète et indépendante d'une VM. Contrairement au snapshot, le clone n'a aucune dépendance avec l'original.

Quand cloner ?

Le clonage répond à un besoin de duplication, jamais à un besoin de protection. Si la question que vous vous posez commence par « et si ça casse », c'est un snapshot ou un backup qu'il vous faut, pas un clone : le clone coûte le prix d'une copie intégrale du disque et vous laisse une seconde machine à administrer. Le tableau donne les quatre cas qui reviennent le plus souvent.

Situation	Cloner ?
Créer une VM de test à partir d'un template	Oui
Dupliquer un serveur pour load balancing	Oui
Sauvegarder avant une mise à jour	Non, c'est un backup
Tester une config temporairement	Non, c'est un snapshot

Glissez pour voir

Cloner avec virt-clone

1. Arrêter la VM source (recommandé)

   virsh shutdown ma-vm

   Note

   Le clonage d'une VM en cours d'exécution est possible, mais il risque de produire un clone à l'état incohérent, en particulier si la machine héberge une base de données dont les écritures en cours ne sont pas encore retombées sur le disque.

2. Cloner la VM

   virt-clone \
     --original ma-vm \
     --name ma-vm-clone \
     --auto-clone

   Sortie attendue :

   Allocating 'ma-vm-clone.qcow2'                    | 20 GB  00:00:45
   
   Clone 'ma-vm-clone' created successfully.

   L'option --auto-clone :

   • Génère un nouveau nom de disque
   • Génère une nouvelle adresse MAC
   • Génère un nouvel UUID

3. Vérifier le clone

   virsh list --all | grep -E "ma-vm|clone"

   Sortie attendue :

    -   ma-vm        shut off
    -   ma-vm-clone  shut off

Options de clonage avancées

Spécifier le chemin du nouveau disque :

virt-clone \
  --original ma-vm \
  --name ma-vm-clone \
  --file /var/lib/libvirt/images/ma-vm-clone.qcow2

Cloner avec un disque COW (reflink) sur Btrfs/XFS :

virt-clone \
  --original ma-vm \
  --name ma-vm-clone \
  --reflink

Cette option utilise la copie instantanée du système de fichiers (si supporté). Beaucoup plus rapide qu'une copie complète.

Cloner sans copier certains disques :

virt-clone \
  --original ma-vm \
  --name ma-vm-clone \
  --skip-copy vdb

Utile si vdb est un disque de données partagé.

Attention aux identifiants après clonage

Le clone est une copie exacte. Cela signifie que l'intérieur de la VM a :

• Le même hostname
• Les mêmes clés SSH hôte
• La même adresse IP (si statique)
• Le même machine-id

Conflits réseau et sécurité

Démarrer deux VMs qui portent le même hostname ou la même adresse IP sur un même réseau provoque des conflits difficiles à diagnostiquer, et des clés SSH hôte identiques font tomber toute vérification d'empreinte. Nettoyez ces identifiants dans le clone avant son premier démarrage.

Pour nettoyer un clone, utilisez virt-sysprep :

# Installer si nécessaire
sudo apt install guestfs-tools  # Debian/Ubuntu
sudo dnf install guestfs-tools  # Fedora/RHEL

# Nettoyer le clone (VM arrêtée)
virt-sysprep -d ma-vm-clone

virt-sysprep supprime :

• Les clés SSH hôte (régénérées au boot)
• Le machine-id
• Les logs
• L'historique bash
• Les caches apt/dnf

Partie 3 : Backups, la vraie protection

Un backup est une copie indépendante que vous pouvez restaurer même si l'hôte KVM est détruit. C'est la seule protection contre :

• Panne matérielle de l'hôte
• Corruption du système de fichiers
• Suppression accidentelle
• Ransomware

Stratégie de backup simple

Un backup KVM se résume à deux objets, et oublier l'un des deux rend l'autre inutilisable. Le XML sans les disques redéfinit une machine qui pointe sur des fichiers absents ; les disques sans le XML ne disent ni la quantité de RAM, ni le réseau, ni l'ordre de boot. Un backup complet contient donc :

1. La configuration XML de la VM
2. Le(s) disque(s) de la VM

Backup complet
├── ma-vm.xml          ← Configuration (virsh dumpxml)
└── ma-vm.qcow2        ← Disque (copie)

Backup d'une VM arrêtée

C'est la méthode la plus fiable : pas de risque d'incohérence.

1. Arrêter la VM

   virsh shutdown ma-vm
   # Attendre l'arrêt complet
   virsh domstate ma-vm

2. Exporter la configuration XML

   virsh dumpxml ma-vm > /backup/ma-vm.xml

3. Identifier le(s) disque(s)

   virsh domblklist ma-vm

   Sortie exemple :

    Target   Source
   --------------------------
    vda      /var/lib/libvirt/images/ma-vm.qcow2
    vdb      /var/lib/libvirt/images/ma-vm-data.qcow2

4. Copier les disques

   cp /var/lib/libvirt/images/ma-vm.qcow2 /backup/
   cp /var/lib/libvirt/images/ma-vm-data.qcow2 /backup/

   Copie avec progression

   Pour les gros disques, cp reste muet pendant de longues minutes. rsync ou pv affichent la progression et savent reprendre une copie interrompue :

   rsync -ah --progress /var/lib/libvirt/images/ma-vm.qcow2 /backup/

5. Vérifier l'intégrité

   qemu-img check /backup/ma-vm.qcow2

   Sortie attendue :

   No errors were found on the image.

6. Redémarrer la VM

   virsh start ma-vm

Backup d'une VM en cours d'exécution

Arrêter une machine pour la sauvegarder n'est pas toujours possible. libvirt expose pour cela une API de sauvegarde dédiée, backup-begin, qui fait le travail sans arrêter la VM et sans que vous manipuliez le moindre fichier de disque. C'est la méthode à employer, et elle remplace les recettes artisanales qui circulent encore.

virsh backup-begin ma-vm

La commande répond Backup started et rend la main : la copie se déroule en arrière-plan, pilotée par QEMU. Sans autre argument, libvirt écrit la sauvegarde à côté du disque source, sous le nom du disque suffixé d'un horodatage, par exemple ma-vm.qcow2.1789800752. C'est le mode push, où QEMU pousse lui-même les données vers la destination.

Suivre l'avancement et savoir quand c'est fini :

virsh domjobinfo ma-vm

Tant qu'un travail est en cours, la commande décrit son type et sa progression. Quand backup-dumpxml répond no domain backup job present, la sauvegarde est terminée.

Choisir la destination, et sauvegarder en incrémental

Décrire la sauvegarde dans un fichier XML permet de choisir où elle atterrit, ce qui est indispensable dès que la destination est un autre disque ou un montage réseau. Le même fichier sert de base aux sauvegardes incrémentales.

backup-full.xml

<domainbackup mode='push'>
  <disks>
    <disk name='vda' backup='yes' type='file'>
      <driver type='qcow2'/>
      <target file='/backup/ma-vm-full.qcow2'/>
    </disk>
  </disks>
</domainbackup>

Un checkpoint est le marqueur qui rend l'incrémental possible : il note l'état des blocs à un instant, et la sauvegarde suivante ne copiera que ce qui a changé depuis. On le crée en même temps que la sauvegarde complète.

checkpoint-base.xml

<domaincheckpoint>
  <name>base</name>
</domaincheckpoint>

virsh backup-begin ma-vm \
  --backupxml /etc/libvirt/backup-full.xml \
  --checkpointxml /etc/libvirt/checkpoint-base.xml

La sauvegarde incrémentale se déclare ensuite en nommant le checkpoint de départ, dans un élément <incremental> :

backup-incr.xml

<domainbackup mode='push'>
  <incremental>base</incremental>
  <disks>
    <disk name='vda' backup='yes' type='file'>
      <driver type='qcow2'/>
      <target file='/backup/ma-vm-incr.qcow2'/>
    </disk>
  </disks>
</domainbackup>

Le gain se mesure immédiatement : sur une machine de test dont rien n'avait changé entre les deux passes, la sauvegarde complète pesait 524 Ko et l'incrémentale 196 Ko. Sur une VM réelle, l'écart se compte en dizaines de gigaoctets épargnés à chaque passage.

Deux détails de syntaxe qui font échouer la commande

--checkpointxml attend un chemin de fichier, pas du XML passé en ligne de commande : lui donner directement la balise produit une erreur d'ouverture. Et incremental est un élément de <domainbackup>, pas un attribut : écrire <domainbackup incremental='base'> fait rejeter le document par le schéma, avec Invalid attribute incremental for element domainbackup.

L'ancienne méthode, et pourquoi elle n'est plus la bonne

Avant backup-begin, sauvegarder à chaud imposait un enchaînement manuel : créer un snapshot externe, copier le disque devenu figé, puis refusionner avec blockcommit --active --pivot et supprimer l'overlay. Vous la croiserez dans beaucoup de tutoriels, et il est utile de la comprendre, parce qu'elle explique ce que backup-begin automatise.

Elle n'est plus recommandée pour une raison précise : chacune de ses étapes manipule des fichiers de disque à la main pendant que la VM écrit dedans. Une erreur d'ordre, un pivot oublié ou un overlay supprimé trop tôt ne donnent pas un message d'erreur, ils donnent une perte de données. L'API fait le même travail sans jamais vous confier ces fichiers.

Ne copiez jamais un .qcow2 en cours d'utilisation. Un cp ou un qemu-img convert lancé sur le disque d'une machine allumée lit un fichier que QEMU est en train de modifier. QEMU verrouille d'ailleurs ses images pour empêcher les accès concurrents incompatibles. Le résultat, quand il est produit, démarre parfois, avec un journal à rejouer et, pour une base de données, une corruption silencieuse.

Snapshot cohérent : les trois niveaux, et ce que --quiesce garantit

L'option --quiesce demande au QEMU Guest Agent, installé dans la VM, de geler les systèmes de fichiers le temps de la prise. Sans cet agent, la commande ne se dégrade pas en silence, elle échoue franchement :

error: argument unsupported: QEMU guest agent is not configured

C'est un bon comportement : vous savez tout de suite que vous n'avez pas ce que vous croyiez avoir. Sans l'option, le même snapshot passe quand même, mais il ne vaut pas la même chose. Trois niveaux de cohérence se distinguent, et les confondre est l'erreur classique de la sauvegarde :

Niveau	Ce que vous obtenez	Comment
Crash-consistent	L'équivalent d'une coupure de courant. Le système redémarre en rejouant son journal	snapshot d'une VM active, sans --quiesce
Filesystem-consistent	Le système de fichiers est propre, aucun journal à rejouer	--quiesce, avec l'agent installé
Application-consistent	Les données applicatives sont cohérentes entre elles	--quiesce plus un hook qui met la base en mode sauvegarde

Glissez pour voir

La troisième ligne est celle qu'on oublie. Geler un ext4 ou un XFS ne dit rien de ce qu'une base de données garde encore dans ses tampons ou dans une transaction ouverte. Pour un PostgreSQL ou un MySQL, la cohérence des fichiers ne fait pas la cohérence des données : il faut soit un hook de gel côté applicatif, soit un pg_dump ou un mysqldump classique, soit la sauvegarde native du moteur.

Restaurer un backup

Une sauvegarde qui n'a jamais été restaurée reste une hypothèse. La restauration se joue en deux mouvements : remettre les disques à leur place, puis réinjecter la définition avec virsh define. L'ordre compte, car un domaine défini avant que ses fichiers existent refusera de démarrer.

1. Copier les disques vers leur emplacement

   cp /backup/ma-vm.qcow2 /var/lib/libvirt/images/

2. Adapter le XML si nécessaire

   Si vous restaurez sur un hôte différent, vérifiez :

   • Les chemins des disques
   • Le nom du réseau
   • Les capabilities CPU

3. Importer la VM

   virsh define /backup/ma-vm.xml

   Sortie attendue :

   Domain 'ma-vm' defined from /backup/ma-vm.xml

4. Démarrer la VM

   virsh start ma-vm

5. Vérifier

   virsh console ma-vm
   # ou SSH si le réseau fonctionne

Script de backup automatisé

Voici un script simple pour automatiser les backups :

#!/bin/bash
# backup-vm.sh - Backup d'une VM KVM
# Usage: ./backup-vm.sh <nom-vm> <dossier-backup>

VM_NAME="${1:?Usage: $0 <vm-name> <backup-dir>}"
BACKUP_DIR="${2:?Usage: $0 <vm-name> <backup-dir>}"
DATE=$(date +%Y%m%d-%H%M%S)

# Créer le dossier de backup
mkdir -p "${BACKUP_DIR}/${VM_NAME}/${DATE}"
DEST="${BACKUP_DIR}/${VM_NAME}/${DATE}"

echo "=== Backup de ${VM_NAME} vers ${DEST} ==="

# Exporter la config XML
echo "[1/3] Export de la configuration..."
virsh dumpxml "${VM_NAME}" > "${DEST}/${VM_NAME}.xml"

# Identifier et copier les disques
echo "[2/3] Copie des disques..."
for DISK in $(virsh domblklist "${VM_NAME}" --details | awk '/disk/ {print $4}'); do
  echo "  → Copie de ${DISK}..."
  DISK_NAME=$(basename "${DISK}")
  cp "${DISK}" "${DEST}/${DISK_NAME}"
done

# Vérification
echo "[3/3] Vérification..."
for QCOW in "${DEST}"/*.qcow2; do
  qemu-img check "${QCOW}" > /dev/null && echo "  [OK] ${QCOW}" || echo "  [ERREUR] ${QCOW}"
done

echo "=== Backup terminé : ${DEST} ==="
ls -lh "${DEST}"

Utilisation :

chmod +x backup-vm.sh
./backup-vm.sh ma-vm /mnt/backup

Tableau récapitulatif

Le réflexe utile n'est pas de connaître les commandes par cœur, c'est de partir du besoin et de laisser le tableau désigner l'outil. Les deux premières lignes relèvent du test réversible, les deux dernières de la protection réelle, et la ligne « Dupliquer » n'est ni l'une ni l'autre : elle fabrique une machine de plus.

Besoin	Technique	Commande clé
Tester une mise à jour	Snapshot	virsh snapshot-create-as
Revenir en arrière	Revert	virsh snapshot-revert
Dupliquer une VM	Clone	virt-clone --auto-clone
Protéger contre les pannes	Backup	dumpxml + copie disque
Restaurer une VM	Import	virsh define

Glissez pour voir

Erreurs fréquentes

Ces cinq situations couvrent la quasi-totalité des demandes d'aide sur le sujet. Les deux premières sont des messages d'erreur que libvirt affiche clairement. Les trois suivantes sont plus vicieuses, puisque la commande réussit : le défaut n'apparaît qu'à l'usage, au démarrage du clone ou le jour de la restauration.

Erreur	Cause	Solution
error: domain is not running	Snapshot avec --quiesce sur VM arrêtée	Retirer --quiesce
Snapshot not found	Mauvais nom ou snapshot déjà supprimé	virsh snapshot-list
Clone très lent	Copie complète de gros disques	Utiliser --reflink si Btrfs/XFS
VM clone avec même IP	Identifiants non nettoyés	virt-sysprep
Backup corrompu	Copie de VM en cours sans snapshot	Utiliser la méthode snapshot + copie

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

Si une seule idée doit rester de ce guide, c'est que le mot sauvegarde ne s'applique qu'à une copie qui survit à la destruction de l'hôte. Un snapshot n'y survit pas, un clone laissé sur le même disque non plus. Les six points ci-dessous découlent tous de cette distinction.

1. Snapshot n'est pas backup, le snapshot dépend du disque original
2. Snapshot = test temporaire, créez, testez, supprimez
3. Clone = copie indépendante, pensez à nettoyer les identifiants
4. Backup = XML + disque(s), testez la restauration régulièrement
5. Pas plus de 2-3 snapshots, au-delà, les performances se dégradent
6. Quiesce améliore la cohérence mais nécessite l'agent QEMU

Pour aller plus loin

• Terraform + libvirt : Recréer une VM à l'identique par le code, ce qu'aucun clone manuel ne garantit dans la durée.
• Dépannage réseau KVM/libvirt : La marche à suivre quand un clone démarre mais reste sans adresse IP.

×

📖 Voir la documentation →