Ce que les modes vzdump de Proxmox garantissent vraiment

Proxmox propose trois modes de sauvegarde dans une seule liste déroulante, ce qui leur donne l’air d’être trois vitesses d’une même chose. Ils ne le sont pas. Ils diffèrent par ce qui arrive à la machine invitée pendant l’opération, et donc par ce dont l’archive est réellement une copie.

La version courte, puis la longue :

Le mot qui porte tout le poids de ce tableau est crash-consistent. Il signifie que l’archive correspond à ce qu’aurait été le disque si quelqu’un avait arraché le câble d’alimentation à cet instant précis. Un système de fichiers journalisé s’en relève. Une base de données dont une transaction était en vol, peut-être pas, et une application qui répartit son état sur deux fichiers ne saura jamais que l’un des deux est plus ancien que l’autre.

snapshot n’implique aucun gel du système de fichiers

snapshot est le mode par défaut, et le seul qui n’interrompe rien. Proxmox prend un instantané au niveau du stockage et lit la sauvegarde depuis celui-ci, si bien que l’invité continue d’écrire sur le volume vivant pendant toute la durée de l’opération.

Il existe un moyen d’améliorer cette archive : l’agent invité QEMU peut geler le système de fichiers à l’intérieur de l’invité au moment où l’instantané est pris, ce qui vide les écritures en attente et donne une archive que l’invité lui-même considère comme propre. Si l’agent invité est installé, en cours d’exécution et qu’il répond, c’est ce qui se produit.

Le piège est dans ce « si ». Rien dans le résultat de l’API ne vous dit si le gel a bien eu lieu. La tâche vzdump renvoie un identifiant de tâche puis, une fois terminée, un état. Savoir si qemu-guest-agent a répondu à la demande de gel est une ligne dans le journal de la tâche, pas un champ que vous pouvez relire.

C’est un point de décision pour quiconque automatise par-dessus, et il mérite qu’on le tranche délibérément. Lorsque nous avons construit le chemin de sauvegarde de notre intégration Proxmox, nous avons fini par enregistrer la cohérence comme ce qui s’est produit, jamais comme ce qui a été demandé : une sauvegarde stop est enregistrée comme cohérente, et snapshot comme suspend sont enregistrés comme crash-consistent, un point c’est tout. Il existe dans notre schéma une valeur pour « l’invité a été figé » et l’agent ne l’émet jamais, car l’émettre reviendrait à prétendre connaître un gel que l’API ne nous permet pas de vérifier.

Une archive décrite comme légèrement moins bonne qu’elle ne l’est ne coûte rien. Une archive décrite comme meilleure qu’elle ne l’est coûte la seule restauration qui compte.

suspend met l’invité en pause, sans être un entre-deux

suspend se lit mieux qu’il ne se comporte. On imagine volontiers un « snapshot, mais en plus sûr », un compromis entre aucune interruption et une interruption complète. Ce qu’il fait réellement, c’est mettre l’invité en pause le temps que les données soient lues.

Il offre exactement la même garantie de cohérence crash-consistent que snapshot, car mettre une machine en pause n’équivaut pas à la laisser vider ses tampons et se stabiliser. Vous obtenez une interruption sans promesse plus forte. Son domaine d’emploi est étroit : un stockage incapable de prendre le moindre instantané, où le mode snapshot n’aurait rien depuis quoi lire.

stop est la seule garantie honnête

stop éteint l’invité, le sauvegarde, puis le redémarre. C’est l’interruption la plus longue et le seul mode où l’archive est sans ambiguïté la copie d’un système de fichiers que personne n’était en train d’écrire.

Pour un serveur de base de données que quelqu’un restaurera sous pression à trois heures du matin, ce n’est pas un prix élevé. Pour une flotte de serveurs web, c’est un prix que personne ne paiera toutes les nuits. Les deux sont des réponses correctes à des questions différentes, et c’est bien pour cela que le mode appartient à la politique de sauvegarde et non à un réglage global unique.

Un détail d’implémentation compte ici. Puisque stop et suspend interrompent tous deux une machine en fonctionnement, une valeur de mode absente ou non reconnue ne doit jamais retomber sur l’un des deux. Dans notre schéma de commande, le mode voyage sous la forme du mot Proxmox littéral (snapshot, suspend, stop) plutôt que dans un vocabulaire à nous, et une valeur non renseignée se résout en snapshot. Une table de traduction entre nos mots et les leurs placerait une erreur de traduction exactement là où une erreur de traduction éteint la machine d’un client.

Les paramètres qui décident si le travail démarre

Avant la cohérence vient une question plus terre à terre : vzdump va-t-il seulement se lancer. Quatre éléments de la requête en décident, et trois d’entre eux échouent d’une manière difficile à lire.

Le stockage cible doit accepter les sauvegardes. Un stockage Proxmox possède une liste content, et seul un stockage dont la liste comprend backup peut recevoir un vzdump. Ce n’est pas indicatif. Envoyez le travail vers un stockage qui ne contient que des images disque et Proxmox le refuse avec un message du genre storage 'x' does not support vzdump backups. Exact, et dénué de sens pour le client qui vient de cliquer sur le bouton. Mieux vaut vérifier avant de soumettre, pour que le refus puisse dire « ce stockage n’accepte pas les sauvegardes » à la place.

Un cas voisin : un stockage qui apparaît dans la liste des ressources du cluster avec l’état unknown est configuré mais ne répond pas. Un partage NFS hors service ressemble en tout point à une cible valide, jusqu’au moment où le travail échoue.

La compression a une valeur qui n’est pas le mot attendu.

Proxmox écrit « aucune compression » sous la forme 0, et non none. Envoyer none est le genre d’erreur qui produit un refus silencieux plutôt qu’un refus clair, et c’est la raison pour laquelle notre suite de tests vérifie la chaîne exacte qui quitte l’agent, au lieu de se contenter de constater que l’appel a réussi.

La notification par courriel est bavarde par défaut, et adressée à la mauvaise personne. Sans un mailnotification=failure explicite, Proxmox écrit à root@pam après chaque sauvegarde. Sur une machine pilotée depuis une plateforme, cela revient à écrire à l’hébergeur au sujet de ce qu’a fait son client.

Deux champs optionnels méritent d’être connus. notes-template attache une note à l’archive, et Proxmox y développe ses propres marqueurs comme {{guestname}}. protected=1 marque une archive comme protégée, et Proxmox refusera ensuite de l’élaguer. C’est le mécanisme qu’il vous faut pour la copie prise juste avant une opération risquée, et exactement le mauvais réglage par défaut pour un travail nocturne.

La rétention n’est pas un paramètre de vzdump

Il n’existe aucun réglage de rétention sur la requête de sauvegarde. L’élagage se configure sur le stockage, dans Proxmox, et c’est le propriétaire du stockage qui décide combien de temps les copies vivent.

Cela a une conséquence de conception pour qui construit par-dessus : un panneau qui propose un champ « conserver 7 copies » va soit toucher à la configuration du stockage, soit supprimer les archives lui-même. Nous n’avons choisi ni l’un ni l’autre, et nous le disons, plutôt que de laisser croire le contraire avec un champ qui ne fait rien.

Un dépassement de délai n’est pas un échec

Le vzdump d’une grosse machine peut survivre à n’importe quel délai d’expiration raisonnable. Quand cela arrive, l’essentiel est de comprendre que rien n’a été annulé : le travail continue de tourner sur l’hyperviseur, et il se terminera ou échouera à son propre rythme.

Un dépassement de délai est donc un constat sur votre connexion, pas sur la sauvegarde. L’exécution reste ouverte, l’identifiant de tâche reste valide, et la chose honnête à faire pour une interface est d’afficher « toujours en cours » et de réconcilier plus tard. L’alternative, la marquer en échec et laisser quelqu’un en lancer une deuxième, met deux travaux vzdump sur le même stockage pour la même machine.

Pendant qu’il tourne, la véritable progression est disponible : vzdump écrit des lignes comme 12% (1.2 GiB of 10.0 GiB) dans son journal de tâche. Une barre de progression alimentée par cela est honnête. Une barre de progression alimentée par une estimation est une supposition avec un signe pourcentage à la fin.

Restaurer est une autre question, et unique en est la clé

La question du mode s’arrête là où l’archive existe. La restauration a son propre piège, et c’est un piège réseau.

Restaurez une archive dans une nouvelle machine sans demander de nouveaux identifiants et la nouvelle machine hérite des adresses MAC de l’originale. Si l’originale tourne toujours, vous avez désormais deux machines avec la même MAC sur le même pont, et le symptôme n’est pas « la restauration a échoué » mais « le réseau de la machine de production s’est mis à déraper ». L’option unique de l’appel de restauration est ce qui empêche cela, et sur une plateforme qui restaure à côté d’une originale en fonctionnement, ce n’est pas une option mais une condition préalable.

Deux autres points valent d’être connus avant la première restauration :

• storage ne veut pas dire la même chose ici. À la sauvegarde, c’est l’endroit où va l’archive, et il lui faut backup dans sa liste de contenus. À la restauration, c’est l’endroit où atterrissent les disques restaurés, et il lui faut images. Même nom de champ, exigence différente.
• Seuls les disques reviennent. Une machine restaurée est une machine dotée des disques et du matériel de l’archive. Les attributions d’adresses, les règles de pare-feu et toute l’automatisation attachée à l’originale vivent dans vos propres systèmes, pas dans le fichier vzdump, et ils ne voyagent pas avec lui.

Ce qui n’est pas mesuré ici

Tout ce qui précède sur la forme des appels provient du schéma d’API de Proxmox et de notre travail de développement contre celui-ci ; la sémantique des modes est celle de Proxmox, décrite dans sa propre documentation.

Ce que nous nous refusons délibérément à affirmer, c’est ce que coûte chaque mode en temps. Nous n’avons aucune durée de pause mesurée pour suspend ni aucune indisponibilité mesurée pour stop : cela dépend de l’invité, du stockage et du volume de mémoire modifiée, et un chiffre mesuré sur une machine serait cité comme un chiffre général. Ceux-là doivent venir de votre propre matériel.

Deux autres lacunes méritent d’être nommées. Tout ce qui précède concerne les invités QEMU ; les sauvegardes de conteneurs ont leurs propres règles autour des points de montage et des montages liés, et nous ne les avons pas mesurées. Et il n’y a nulle part ici de chemin incrémental : vzdump vers un stockage ordinaire écrit une archive complète à chaque fois. La sauvegarde incrémentale, c’est ce à quoi sert Proxmox Backup Server, et c’est un autre logiciel, avec un autre ensemble de promesses.

Ce texte est né de la construction du chemin de sauvegarde Proxmox pour Provibr, un panneau de gestion de serveurs destiné aux hébergeurs, où une sauvegarde décrite comme meilleure qu’elle ne l’est serait le pire bug imaginable. Les notes d’installation côté hyperviseur se trouvent dans la documentation Proxmox, et la page intégration Proxmox couvre ce que l’agent sait faire.