L’intégration entre Veeam Backup & Replication 13.1 et Proxmox VE a suscité beaucoup d’intérêt, car elle promet des sauvegardes par image sans nécessiter l’installation de composants permanents sur les nœuds du cluster. Toutefois, son fonctionnement interne est peu documenté publiquement. Après avoir analysé un laboratoire doté d’un cluster de Proxmox VE 9 et observé le comportement lors d’une sauvegarde, il devient possible de mieux comprendre comment le processus s’effectue réellement.

Les clés de la sauvegarde Veeam sur Proxmox en 20 secondes

• Veeam n’installe pas de logiciel permanent sur les nœuds Proxmox pendant la sauvegarde.
• Elle utilise une machine virtuelle worker créée et gérée automatiquement.
• Le disque de la machine protégée est exporté via NBD par QEMU.
• Le worker reçoit cette exportation sans accéder directement au volume original.
• Le mécanisme repose sur des fonctionnalités natives de QEMU.

L’un des aspects les plus remarquables de cette implémentation est que l’hyperviseur reste pratiquement inchangé. Contrairement à d’autres plateformes de virtualisation où des composants persistants ou des services spécifiques sont déployés sur les hôtes, lors de ce processus aucun paquet supplémentaire de Veeam n’est installé sur les nœuds Proxmox, ni d’agents permanents dans la machine virtuelle protégée.

Le laboratoire utilisé comprenait un cluster de Proxmox VE 9 à deux nœuds, une installation indépendante de Veeam Backup & Replication 13.1 et une machine virtuelle Windows avec un disque de 40 Go.

Le protagoniste : la machine virtuelle worker

En réalité, ce n’est pas le nœud Proxmox qui effectue le travail principal, mais une machine virtuelle nommée worker.

Lors de l’exécution de la sauvegarde, Veeam :

• Reconfigure automatiquement le worker.
• Le démarre au début du processus de sauvegarde.
• Vérifie via QEMU Guest Agent que le système a démarré correctement.
• Effectue la copie de sécurité.
• Éteint à nouveau le worker une fois le processus terminé.

Cela explique pourquoi, dans une installation standard du plugin Proxmox, ces workers restent généralement éteints et ne s’activent que lors des opérations de sauvegarde.

Communication directe avec QEMU

Une autre observation intéressante est apparue lors de l’analyse du moniteur QMP (QEMU Machine Protocol) de la machine virtuelle protégée.

Pendant la sauvegarde, une requête manuelle au moniteur a renvoyé un timeout. Le fonctionnement normal reprenait une fois le processus terminé.

Il s’agit d’une simple observation propre à ce laboratoire, et non d’une limitation documentée par Veeam ou Proxmox. Néanmoins, cela suggère qu’il est préférable d’éviter toute opération administrative sur la machine virtuelle, comme lancer un snapshot supplémentaire ou initier une migration à chaud, pendant la sauvegarde.

Le disque n’est jamais directement ouvert par le worker

La partie la plus intrigante de l’analyse a été l’inspection des processus QEMU.

Il était initialement logique de penser que le worker ouvrirait directement le volume de stockage de la machine protégée. Mais ce n’est pas le cas.

Au cours du test :

• Le processus QEMU du worker ne maintenait pas de descripteur ouvert sur le volume de la VM.
• C’était le QEMU de la VM protégée qui gardait le disque ouvert.
• Ce même processus lançait un serveur NBD (Network Block Device) écoutant sur l’interface loopback.
• Le QEMU du worker se connectait simplement à cette exportation NBD.

Les captures du trafic entre ces processus ont même permis d’observer le handshake initial du protocole, avec les chaînes NBDMAGIC et IHAVEOPT, caractéristiques du protocole NBD.

En résumé, le disque ne passe jamais directement au worker. Ce qu’il reçoit est une exportation réalisée par le QEMU de la machine protégée, en utilisant des mécanismes natifs de l’hyperviseur.

Une compréhension cohérente des snapshots

Ce constat permet également de mieux saisir le comportement des snapshots.

Pendant la sauvegarde, les nouvelles écritures sur la VM continuent d’être stockées selon la configuration choisie pour les snapshots (soit sur la LUN elle-même, soit sur un stockage externe temporaire).

Mais, quelle que soit cette configuration, le worker lit toujours les données depuis l’exportation NBD fournie par le QEMU de la machine protégée, sans accéder directement au volume physique.

Ce détail explique une question courante lors de l’analyse du stockage en pleine opération de copie : le snapshot n’a pas besoin d’être présenté comme un volume séparé pour que le worker puisse le lire.

Un aspect crucial pour la production

Au-delà du point technique, un aspect important à considérer avant d’adopter cette solution en environnement professionnel concerne l’accès aux hôtes Proxmox.

La documentation de Veeam indique que cet accès requiert un compte avec des privilèges root ou la capacité d’élévation de privilèges vers root. De plus, l’authentification par clés SSH ou par MFA n’est actuellement pas supportée pour cet accès.

Dans les organisations appliquant des politiques strictes de sécurité ou de contrôle d’accès privilégié, cette question doit être anticipée, car il pourrait être nécessaire d’établir des exceptions spécifiques dans la politique de sécurité.

Bien que Veeam abstraie une grande partie du fonctionnement interne de son intégration avec Proxmox VE, cette étude montre que le processus exploite principalement des capacités déjà présentes dans QEMU, notamment l’exportation de disques via NBD. Résultat : un mécanisme qui évite l’installation de logiciels permanents sur les hôtes, minimise l’impact sur l’hyperviseur et délègue la charge de traitement à une machine virtuelle temporaire gérée automatiquement par la plateforme de sauvegarde.