Niveau : débutant

Nous avons vu dans l'article précédent ce qu'étaient exactement les snapshots, et l'une des applications que l'on pouvait en faire, à savoir créer des sauvegardes live des disques des machines virtuelles.
Cette fonctionnalité est tellement "magique", que nous avons tendance à en user et abuser.
Or, ajouter cette couche à l'hyperviseur hyper optimisé ESXi a aussi un coût, et des contreparties.
Nous allons maintenant voir dans cet article quelles sont les "best practices" pour l'utilisation les snapshots ESXi, de façon plus générale.

"N'abusons de rien, sauf de la modération" - Jean Lesage

L'article précédent explique "le pourquoi du comment" des snapshots :
Sauvegarde de machines virtuelles

Dans l'article précédent, j'ai expliqué comment fonctionnait une sauvegarde live de machine virtuelle :
elle met le disque d'origine en lecture seule, et ajoute un nouveau disque qui sera désormais utilisé pour les opérations d'écriture, le "delta" du disque d'origine.

Cela est très pratique pour effectuer des sauvegardes, et comme nous pouvons prendre plusieurs snapshots par machine virtuelle, nous pouvons aussi nous en servir pour faire une sorte de "versionning", c'est à dire avoir la possibilité de revenir à un état antérieur du disque. C'est totalement transparent, et instantané, donc extrêmement pratique.

Toutefois, cela a aussi de nombreuses contreparties :
- le snapshot n'est que le delta du disque d'origine, et non pas une copie : le disque d'origine est donc nécessaire au bon fonctionnement du snapshot
- les snapshots peuvent se chaîner, ils représentent alors une "sauvegarde incrémentale", récursive, de l'état du disque : chaque snapshot est dépendant du précédent, le premier restant dépendant de l'image disque d'origine
- cela en fait donc un système fragile : plus il y aura de snapshots dans la "chaine", et plus il y aura de dépendances
- chaque snapshot peut atteindre la taille de l'image d'origine, selon la quantité de modifications effectuées dans les fichiers delta
- l'espace disque pris par les snapshots n'entre pas en compte dans les limitations de l'espace alloué à la machine virtuelle
- les snapshots ont une influence négative sur les performances : à chaque opération de lecture, ESXi devra "consolider" en live les données d'un secteur, en prenant en compte le secteur du disque d'origine, plus les changements apportés dans chacun des snapshots
- une machine virtuelle avec de fréquentes opérations d'écriture (serveur e-mails, base de données, logs centralisés) sera évidemment plus impactée d'un point de vue performances qu'une machine avec des opérations d'écriture rares
- si l'on change la taille du disque virtuel alors qu'un ou plusieurs snapshots sont présents, il y aura corruption des données !

Pour plus de précisions, je vous renvoie à l'article VMware d'origine, en anglais
Best practices for virtual machine snapshots in the VMware environment (1025279)

Conclusion

Nous avons vu que les snapshots sont très pratiques, mais qu'ils avaient aussi un nombre d'inconvénients.
C'est pour cela que je les recommande avant tout pour la sauvegarde "live" des machines virtuelles.
Nous pouvons aussi nous en servir lorsqu'on a une maintenance importante à faire sur une VM : un gros changement de configuration, ou une opération de transformation sur une grande quantité de données.
Toutefois, il faut garder à l'esprit que cette possibilité de revenir en arrière doit être temporaire, et les snapshots consolidés avec le disque d'origine aussitôt que vos changements sont validés.
Si vous cherchez un outil de versionning persistent, les snapshots ESXi ne sont absolument pas l'outil qu'il vous faut ...

Et bien-sûr, un rappel de la plus haute importance : les snapshots ne sont pas des sauvegardes !

Installation du script de sauvegarde ghettoVCB :
Sauvegarde d'un hôte VMware ESXi grâce au script ghettoVCB