Sauvegarde Proxmox et Veeam : grille de décision entre Veeam Backup & Replication et Proxmox Backup Server

Comparatif multi-critères, TCO 2026 et cas d'usage hybride pour les DSI qui migrent VMware vers Proxmox.

Rédigé par Nina Kristianov, analyste solutions IT B2B chez Foxeet · Mis à jour le 2026-07-28 · 12 min de lecture

La migration VMware vers Proxmox VE s'est accélérée depuis le rachat de VMware par Broadcom fin 2023. Les DSI qui la pilotent tombent presque toujours sur la même bifurcation : rester chez Veeam avec le plugin sorti en décembre 2024, ou passer à Proxmox Backup Server (PBS) intégré à la distribution. Le choix n'est pas trivial. La sauvegarde Proxmox et Veeam couvre en réalité deux besoins différents selon la trajectoire du parc.

Cet article compare les deux approches sur cinq axes concrets : coût de licensing, RTO/RPO en production, maturité de l'environnement, effort de migration et cas d'usage hybride VMware/Proxmox. Les chiffres viennent de la documentation officielle Veeam Helpcenter 12.3, du manuel PBS 3.4 et des retours publics indexés (Enix, IT-Connect, mailing lists Proxmox de 2025). Nous n'avons pas pu vérifier tous les prix Veeam en France sans passer par un revendeur — les fourchettes citées viennent des grilles publiques et des devis mentionnés en forum, à confirmer sur un cas précis.

L'objectif reste simple : donner une grille de sélection utilisable par un responsable infrastructure qui doit trancher dans les six mois, sans commander deux POC parallèles.

Sauvegarde Proxmox et Veeam : ce que le plugin V12.3 change réellement

Veeam a publié le plugin Proxmox VE en décembre 2024 avec la version 12.3 de Backup & Replication. Techniquement, il s'agit d'un composant Linux appelé VM Worker déployé sur chaque nœud PVE cible. Le worker parle à l'API Proxmox, orchestre les snapshots QEMU et transfère les blocs vers un repository Veeam standard (Windows, Linux hardened repository, S3, tape).

Ce que le plugin apporte concrètement au périmètre backup proxmox veeam :

  • Sauvegarde application-aware sur les VM Windows et Linux via VSS et pre-freeze scripts, à parité avec le plugin vSphere.
  • Réplication de VM entre deux clusters Proxmox, avec bascule assistée.
  • Instant VM Recovery : la VM démarre directement depuis le repository Veeam avant restauration complète.
  • Intégration au catalogue Veeam ONE et aux rapports de conformité existants (ISO 27001, HDS).

Ce qu'il ne fait pas encore : la déduplication au niveau du repository sur les VM Proxmox reste inférieure à celle observée sur vSphere, faute de Changed Block Tracking natif équivalent. Veeam s'appuie sur les dirty bitmaps QEMU, qui perdent leur état à chaque redémarrage du nœud. La première sauvegarde après reboot d'un hyperviseur devient donc une full complète, pas une incrémentale.

En pratique. Sur un cluster de 40 VM avec reboot mensuel de maintenance, cette limite ajoute environ 2 TB de fenêtre de sauvegarde par nœud rebooté. Prévoir la bande passante repository et le temps de rétention en conséquence, sinon les jobs débordent sur les heures ouvrées.
sauvegarde Proxmox et Veeam — illustration

Backup proxmox veeam contre Proxmox Backup Server : le comparatif critère par critère

La comparaison utile ne porte pas sur "qui sauvegarde le mieux", mais sur ce que chaque outil compense chez l'autre : chaque composant que vous gardez ou retirez compense une faiblesse ailleurs dans la chaîne. Le tableau ci-dessous place les deux produits côte à côte sur les critères qui pèsent vraiment dans un arbitrage backup proxmox to veeam versus PBS.

CritèreVeeam B&R 12.3Proxmox Backup Server 3.4
Coût licence (annuel, 40 sockets)~28 000 € (VUL socket, Enterprise Plus)Gratuit (support Proxmox 1 070 €/socket Premium)
Déduplication typiqueRatio 3:1 à 8:1 selon workloadRatio 10:1 à 30:1 (fixed-chunk 4 MB)
Restauration bare-metalNative, tout OSNative pour VM, LiveCD pour hôte PVE
Immuabilité anti-ransomwareHardened Repository Linux, S3 Object LockVerify + prune-only role, pas d'immuabilité native avant 3.5
Réplication multi-siteNative, bi-directionnelleSync jobs unidirectionnels
Support tape LTOComplet, chained mediaBasique via proxmox-tape

Coût de licensing : le vrai calcul

Sur un cluster Proxmox de 40 sockets, Veeam Universal License représente environ 700 €/socket/an en France pour l'édition Enterprise Plus (chiffre issu de devis 2025 mentionnés sur les forums Proxmox et confirmé par plusieurs intégrateurs). PBS est gratuit ; le support Proxmox Community coûte 115 €/socket/an, Basic 355 €, Standard 555 €, Premium 1 070 €. Sur cinq ans, l'écart TCO dépasse 100 000 € en faveur de PBS pour un parc pur Proxmox.

Le calcul s'inverse dès qu'il faut aussi sauvegarder du VMware résiduel, du Hyper-V, du fichier NAS, du SaaS Microsoft 365 ou de la base de données. Veeam consolide tout dans un seul catalogue ; PBS ne fait que du VM/CT Proxmox et du répertoire Linux via proxmox-backup-client. Sortez du périmètre PVE, le TCO PBS explose parce qu'il faut ajouter un second outil (souvent Bacula ou Restic) qui refait son propre catalogue.

RTO, RPO et PRA : ce que promettent réellement backup proxmox with veeam et PBS

Sur la résilience d'une chaîne de restauration, la bonne question n'est pas la probabilité de casse d'un composant, mais le nombre de composants qui peuvent tomber avant que la restauration devienne impossible.

Une chaîne Veeam typique en production compte cinq maillons : le serveur Veeam Backup Server, la base SQL du catalogue, les proxies (VM Worker sur PVE), le repository primaire et la copie hors site. PBS en compte trois : datastore ZFS local, sync target distant, catalogue intégré. Moins de pièces signifie moins de points de défaillance — mais aussi moins de compensations mutuelles quand une pièce lâche.

Sur un déploiement PBS mono-datastore avec sync unique vers un NAS Synology, la perte simultanée du contrôleur RAID et du NAS annule 100 % du PRA. Sur Veeam avec hardened repository Linux plus copie S3 immuable, il faut compromettre trois systèmes indépendants avant de perdre la donnée. Documentez cette matrice de perte tolérable : c'est elle qui dit où votre chaîne casse, pas le ratio de déduplication.

RTO mesuré en conditions réelles

Sur les benchmarks publiés par IT-Connect en janvier 2026 et les retours Enix, une VM Linux de 200 GB restaure en 8 à 12 minutes via Veeam Instant Recovery (démarrage depuis le repository, migration Storage vMotion en tâche de fond) et en 25 à 40 minutes via PBS avec restauration complète vers un nouveau volume RBD Ceph. L'écart se creuse sur les gros fichiers : une VM de 2 TB reste sous 15 minutes de RTO avec Instant Recovery Veeam, contre 2 à 3 heures avec PBS selon la bande passante datastore.

Pour un RPO horaire, les deux tiennent sans effort. Pour du RPO à 15 minutes sur une VM critique, seul Veeam avec réplication CDP (Continuous Data Protection, licence séparée) descend sous les 5 minutes de perte. PBS ne propose pas de CDP en version 3.4, seulement des snapshots ZFS qu'il faut orchestrer manuellement — solution artisanale, difficile à auditer.

sauvegarde Proxmox et Veeam — repère visuel

Backup proxmox using veeam : quand la migration VMware devient le vrai critère

Le plugin Veeam Proxmox n'a pas été conçu pour les shops 100 % Proxmox — ces derniers seront presque toujours mieux servis par PBS. Il a été conçu pour les DSI qui gèrent une transition VMware vers Proxmox étalée sur 18 à 36 mois, avec cohabitation des deux hyperviseurs pendant toute cette durée.

Dans ce cas de figure, garder Veeam présente trois avantages opérationnels concrets. Les procédures de restauration, les runbooks du plan de reprise d'activité et les tests trimestriels ne changent pas — un acquis intériorisé par les équipes ops et par les métiers, qu'on ne remet pas en cause pendant une migration qui charrie déjà assez d'inconnues techniques. Le second avantage est le catalogue unifié : une seule interface pour retrouver un fichier perdu, qu'il soit sur ESXi ou sur Proxmox, avec le même moteur de recherche indexé. Le troisième est l'audit : les rapports Veeam ONE de conformité et les évidences pour ISO 27001 ou HDS restent valides sans refonte documentaire.

Le piège du plugin en cohabitation

Attention à un point rarement documenté : le VM Worker Veeam sur PVE consomme entre 4 et 8 GB de RAM et 2 vCPU par job actif. Sur un cluster déjà chargé pendant la migration, provisionner deux nœuds dédiés aux workers évite la contention. Nous avons vu des jobs backup proxmox using veeam ralentir les VM de production de 15 à 25 % sur des clusters sous-dimensionnés — la fenêtre de sauvegarde devient un incident métier.

Proxmox Backup Server, Veeam, Bacula : place de chacun sur restauration, PRA et rétention

Bacula Enterprise reste présent dans le comparatif pour deux raisons précises : sa politique de rétention granulaire (concept de volume pool par criticité) et son intégration native au support tape LTO-9. Pour un environnement mixte bare-metal Linux plus Proxmox avec obligation d'archivage bande à 10 ans, Bacula garde une longueur d'avance. Sur tout le reste du périmètre Proxmox Backup Server Veeam Bacula restauration PRA rétention, PBS ou Veeam traitent le sujet plus simplement.

Sur la rétention, PBS applique une politique GFS (grandfather-father-son) via prune-schedule : keep-daily, keep-weekly, keep-monthly, keep-yearly. Veeam propose la même logique via les Backup Copy Jobs et le Scale-Out Backup Repository avec capacity tier vers S3. Sur une rétention légale à 7 ans, S3 Glacier via Veeam coûte environ 0,004 €/GB/mois — soit 480 € annuels pour 10 TB actifs, avec restauration standard sous 12 heures.

Un plan de reprise d'activité crédible ne se mesure pas au ratio de déduplication, mais au temps de restauration testé. Programmez un test PRA trimestriel chronométré et signé par le métier concerné : sans cette signature, votre SLA de sauvegarde Proxmox et Veeam reste une promesse interne que personne n'a validée côté utilisateurs. Beaucoup de DSI financent des sauvegardes mais aucun test de bout en bout — le jour du sinistre, la promesse s'écroule.

Grille de sélection selon votre profil

Trois profils dominent chez les DSI que nous accompagnons sur ces sujets. La décision doit sortir de l'un des trois quadrants suivants — jamais d'un consensus mou entre les deux outils.

Profil A : parc 100 % Proxmox, moins de 30 hôtes

PBS, sans hésiter. Datastore ZFS raidz2 sur serveur dédié, sync quotidien vers un second PBS géographiquement séparé, snapshot ZFS local en complément. Tout est natif — VM, déduplication, restauration bare-metal des CT LXC — et vous économisez entre 15 000 et 40 000 € de licence Veeam par an selon le nombre de sockets. Rien et à décider.

Profil B : migration VMware vers Proxmox sur 24 mois ou plus

Choix pragmatique : Veeam B&R 12.3 sur toute la période de cohabitation, bascule éventuelle vers PBS après retrait complet de vSphere. Le coût de licence Veeam est amorti par la continuité des procédures, la formation évitée et l'absence de rework sur les tests de PRA. Prévoir la migration des points de restauration historiques via export catalogue et rétention parallèle six mois avant coupure.

Profil C : environnement hybride durable (Proxmox, VMware, physique, M365)

Choix consolidé : Veeam B&R avec plugin Proxmox, en gardant les autres modules (Veeam Backup for Microsoft 365, agents physiques Windows/Linux). C'est ici que l'arbitrage catalogue devient le vrai sujet, et il ne se règle pas d'une phrase. La question centrale : quel outil détient la source de vérité, et pour quels workloads ?

La réponse défendable est de faire de la Veeam sauvegarde centralisée le catalogue de référence unique — audit, PRA, recherche de fichier cross-hyperviseur — et de reléguer PBS à un rôle de second niveau local, utile en cas d'incident réseau ou pour absorber la rétention brève des VM Proxmox à haute fréquence de sauvegarde. Le piège classique est le catalogue bicéphale : une partie des points de restauration indexée dans Veeam ONE, une autre dans PBS, sans table de correspondance. Le jour où un opérateur cherche une VM restaurée trois mois plus tôt, il interroge le mauvais catalogue et conclut à tort que la sauvegarde n'existe pas.

Concrètement, tranchez trois arbitrages avant de câbler quoi que ce soit : quelles VM Proxmox sont sauvegardées par Veeam et lesquelles par PBS (jamais les deux sur le même périmètre, sous peine de double comptage de rétention) ; quelle fenêtre de rétention est portée par quel outil (Veeam pour le long terme légal via S3, PBS pour les 7-14 jours à restauration rapide) ; et qui a le droit de purger, sachant que deux moteurs de prune indépendants finissent toujours par diverger. Documentez cette répartition dans le runbook de PRA — l'incohérence entre outils reste l'une des premières causes d'échec de restauration en environnement multi-hyperviseur, bien avant la panne matérielle.

Rétention, immuabilité et anti-ransomware : le compartimentage minimal

L'immuabilité des sauvegardes contre le ransomware ne se joue pas dans le logiciel de backup, mais dans le stockage sous-jacent. Veeam pousse le Hardened Repository Linux : un serveur avec compte SSH temporaire, chattr +i sur les fichiers de backup, et rétention immuable au niveau du système de fichiers XFS. PBS 3.4 n'offre pas d'équivalent natif — la roadmap 3.5 annonce une fonction similaire, à valider quand elle sortira.

Pour un parc PBS avec exigence anti-ransomware réelle, deux compensations tiennent : stockage objet S3 avec Object Lock (WORM) en cible de sync, ou snapshots ZFS avec compte administrateur séparé (le compte de sauvegarde ne peut pas supprimer les snapshots). Sans l'une des deux, PBS reste vulnérable à un attaquant qui compromettrait le compte root du serveur de backup lui-même.

Avant de commander une licence

Les deux outils savent sauvegarder une VM Proxmox proprement ; l'arbitrage se fait ailleurs. Trois questions le tranchent : combien de maillons votre chaîne de restauration peut-elle perdre avant panne totale, qui détient le catalogue si le logiciel de backup proxmox veeam lui-même est compromis, et vos runbooks de PRA sont-ils signés par les métiers ou seulement par l'IT ?

Prochaine étape recommandée : documentez sur une page A4 la matrice de perte tolérable de votre chaîne actuelle, listez les composants qui compensent quelles faiblesses, et testez un PRA complet avant de commander une licence. Un POC croisé de 30 jours (PBS sur un cluster de dev, plugin Veeam sur un autre) coûte moins qu'une décision reversée dans 18 mois avec migration inverse des points de restauration.

Pour aller plus loin