Veeam contre Proxmox Backup Server : comparatif des solutions de sauvegarde de VM

Veeam Backup & Replication et Proxmox Backup Server répondent à deux philosophies distinctes. Le premier vise les environnements hétérogènes, souvent déjà structurés autour de plusieurs hyperviseurs, de baies de stockage et de cibles de sauvegarde variées. Le second privilégie une intégration étroite avec Proxmox VE, une architecture plus simple et un modèle open source particulièrement attractif lorsque le périmètre de virtualisation est homogène.

Le choix ne se résume donc pas à opposer une solution commerciale à une solution libre. Il dépend surtout du parc à protéger, des objectifs de reprise, des exigences de sécurité, des compétences internes et du niveau d’industrialisation attendu autour de la sauvegarde.

Positionnement et périmètre fonctionnel

Veeam Backup & Replication est historiquement une plateforme de protection des données pour environnements virtualisés. Elle couvre VMware vSphere, Microsoft Hyper-V et, selon les éditions et produits associés, des charges de travail physiques, cloud et applicatives. Son intérêt principal est de proposer une couche de sauvegarde unifiée dans des infrastructures où coexistent plusieurs technologies.

Cette polyvalence se traduit par des intégrations nombreuses : vCenter, Hyper-V, Active Directory, Microsoft SQL Server, Oracle, NAS, stockage objet S3 compatible, dépôts Linux renforcés et mécanismes de copie hors site. Une équipe d’exploitation peut ainsi standardiser les politiques, la supervision et les tests de restauration sur un parc qui ne serait pas exclusivement basé sur un seul hyperviseur.

Proxmox Backup Server, ou PBS, est conçu autour de Proxmox VE. Il repose sur un principe direct : Proxmox VE envoie les sauvegardes des VM et conteneurs vers un datastore PBS, lequel gère les blocs dédupliqués, la compression, la rétention et la vérification d’intégrité. L’expérience est particulièrement fluide depuis l’interface de Proxmox VE, sans déployer de proxy de sauvegarde ni maintenir une infrastructure complexe de transport.

Cette spécialisation est une force lorsque Proxmox VE constitue le socle unique ou largement majoritaire de virtualisation. Elle devient une limite si l’organisation doit également protéger de façon centralisée des clusters VMware, Hyper-V, des postes physiques ou des applications dont la sauvegarde nécessite une intégration applicative poussée.

Déduplication et compression : deux approches efficaces, mais différentes

La déduplication et la compression déterminent directement la capacité utile, la durée des fenêtres de sauvegarde et le coût du stockage. Les deux solutions réduisent fortement le volume écrit, mais leur fonctionnement n’est pas identique.

Veeam : réglages fins et déduplication adaptée au repository

Veeam applique plusieurs mécanismes d’optimisation. La déduplication et la compression peuvent être définies au niveau des jobs de sauvegarde, avec des profils qui arbitrent entre consommation CPU, réduction de volume et performances. La solution est capable d’exploiter les spécificités de différents types de dépôts, notamment les repositories Linux, les appliances de déduplication et le stockage objet.

Dans une architecture Veeam, il faut distinguer la réduction de données effectuée par le moteur de sauvegarde de celle éventuellement réalisée par la cible. Une appliance de déduplication ou une baie disposant de ses propres mécanismes peut modifier le meilleur réglage Veeam. Une compression agressive avant envoi peut, par exemple, réduire l’efficacité de la déduplication côté cible dans certains scénarios. Pour aller plus loin, consultez notre guide complet sur la sauvegarde de VM.

Veeam permet également de créer des sauvegardes synthétiques, où de nouveaux points de restauration sont reconstruits à partir de fichiers déjà présents sur le repository, sans relire intégralement les disques de production. Cette fonctionnalité peut réduire la charge sur le réseau et les hyperviseurs, sous réserve que le stockage de sauvegarde supporte correctement les opérations de lecture et d’écriture nécessaires.

PBS : déduplication par chunks et sauvegardes incrémentales natives

PBS stocke les données sous forme de chunks. Lors d’une sauvegarde, les blocs sont découpés, hachés puis comparés à ceux déjà présents dans le datastore. Un chunk connu n’est pas transféré ou stocké à nouveau. Ce mécanisme s’applique efficacement entre les sauvegardes successives d’une même VM, mais aussi entre plusieurs VM ayant des contenus similaires.

La déduplication PBS fonctionne à l’échelle du datastore. Ce point a une conséquence d’architecture importante : regrouper des VM similaires dans le même datastore peut améliorer le taux de réduction. En revanche, séparer les datastores pour des raisons de cloisonnement, de rétention ou de performances limite naturellement le domaine de déduplication.

PBS compresse les données avant leur stockage et utilise une approche pensée pour les sauvegardes incrémentales fréquentes. Le premier backup d’une VM est logiquement plus lourd, tandis que les exécutions suivantes ne transfèrent que les changements et les chunks absents. Dans un environnement Proxmox VE correctement configuré, cela permet souvent des fenêtres courtes sans multiplier les composants.

Un exemple de déclaration de datastore PBS peut ressembler à ceci :

proxmox-backup-manager datastore create pbs-production \
  /mnt/pbs-production \
  --comment "Sauvegardes des VM de production"

La création du datastore n’est cependant que le début. Il faut aussi prévoir les politiques de rétention, les tâches de garbage collection, la vérification d’intégrité et la surveillance de l’espace disque.

Comparaison opérationnelle

Veeam apporte davantage de réglages et de possibilités d’adaptation à des infrastructures complexes. PBS privilégie une architecture plus intégrée, où la déduplication est largement transparente pour l’administrateur.

Pour un parc Proxmox VE, PBS est souvent très efficace sans optimisation poussée. Pour un parc mixte, Veeam offre plus de flexibilité, notamment si les dépôts utilisent des technologies différentes selon les sites ou les contraintes réglementaires.

Dans les deux cas, il ne faut pas dimensionner la capacité sur la seule taille logique des VM. Il faut mesurer le taux de changement quotidien, la croissance, la rétention, les copies secondaires, les contraintes d’immuabilité et la durée nécessaire pour restaurer les services prioritaires.

Granularité de restauration et objectifs de reprise

Une sauvegarde n’a de valeur que si la restauration est réalisable dans le délai attendu. Les écarts entre Veeam et PBS apparaissent surtout sur la granularité, les restaurations applicatives et la capacité à remettre rapidement un service en ligne.

Restauration complète de VM

Les deux solutions restaurent une VM complète. Avec PBS, la restauration s’effectue naturellement vers un cluster Proxmox VE, à partir de l’interface Web ou de la ligne de commande. L’administrateur peut restaurer la VM sous un nouvel identifiant, modifier certains paramètres avant démarrage ou écraser une machine existante selon le scénario.

Exemple de restauration PBS en ligne de commande :

qmrestore \
  pbs:pbs-production:backup/vm/120/2026-09-20T02:15:00Z \
  120 \
  --storage local-lvm \
  --unique 1

La syntaxe exacte dépend de la configuration du stockage et du compte PBS, mais l’idée reste la même : sélectionner un snapshot, cibler une VM et choisir le stockage de destination.

Veeam propose également la restauration complète, avec davantage d’options de redirection selon les plateformes. Il peut restaurer vers l’hyperviseur d’origine, vers un autre hôte, vers un autre cluster, ou effectuer des migrations selon les licences et composants disponibles. Cette souplesse est utile lors d’une reprise sur site secondaire ou d’une sortie de crise dans un environnement hétérogène.

Restauration au niveau fichier

Veeam est généralement plus mature sur la restauration granulaire de fichiers. Son mécanisme de guest file restore permet de parcourir les systèmes de fichiers sauvegardés et de restaurer un fichier ou un répertoire sans restaurer la VM entière. Les workflows sont bien adaptés à Windows comme à Linux, avec des options de transfert vers l’hôte d’origine ou vers un emplacement alternatif.

PBS sait restaurer des fichiers individuels à partir de sauvegardes de VM ou conteneurs Proxmox, notamment via les outils de restauration de fichiers et le montage de sauvegardes. C’est parfaitement exploitable pour un administrateur Linux à l’aise avec les commandes et les formats de stockage. Toutefois, l’expérience est moins riche que celle de Veeam pour les équipes qui attendent une navigation très guidée, des assistants dédiés ou une intégration applicative avancée.

Le point de vigilance est le suivant : restauration de fichier ne signifie pas restauration cohérente d’une application. Retrouver un fichier de base de données ou un fichier de configuration n’est pas équivalent à restaurer une base SQL à un point transactionnel cohérent. Pour aller plus loin, consultez le stockage virtualisé.

Restauration instantanée

Veeam dispose de mécanismes de récupération instantanée, notamment Instant Recovery. Le principe consiste à démarrer une VM directement depuis le repository de sauvegarde, puis à la migrer ultérieurement vers un stockage de production. C’est particulièrement utile pour réduire le RTO d’un service critique, à condition que le repository, le réseau et l’hyperviseur soient dimensionnés pour supporter temporairement cette charge.

Cette capacité est l’un des avantages forts de Veeam dans les contextes où la remise en service doit être très rapide. Elle doit néanmoins être testée : démarrer une VM depuis un dépôt de sauvegarde ne garantit pas des performances comparables à celles du stockage de production.

PBS ne propose pas un équivalent direct aussi intégré de l’Instant Recovery Veeam pour démarrer de façon transparente une VM de production depuis le dépôt de sauvegarde. Il est possible de restaurer rapidement une VM vers un stockage Proxmox VE et d’organiser l’infrastructure pour réduire les délais, mais le modèle reste celui d’une restauration préalable.

Pour une entreprise dont le RTO se mesure en minutes pour plusieurs VM, cette différence est structurante. Pour un environnement où un redémarrage après restauration est acceptable, PBS reste tout à fait pertinent.

Immuabilité, ransomware et principes de défense

L’immuabilité ne doit pas être interprétée comme une propriété magique du stockage. Elle résulte d’une combinaison de mécanismes techniques et organisationnels : séparation des identités, accès réseau limité, conservation non modifiable, supervision, tests de restauration et copie hors du domaine de compromission.

Veeam et les dépôts durcis

Veeam s’intègre avec des repositories Linux renforcés, communément appelés hardened repositories, qui peuvent utiliser une période d’immuabilité. Dans ce modèle, les sauvegardes ne peuvent pas être supprimées ou modifiées pendant la durée définie, y compris si un compte Veeam est compromis, selon l’architecture et les contrôles mis en place.

Veeam prend aussi en charge des cibles objet disposant d’un verrouillage de rétention, comme les implémentations compatibles S3 Object Lock. Cela facilite une architecture de type 3-2-1-1-0 :

• trois copies des données ;
• deux supports ou systèmes différents ;
• une copie hors site ;
• une copie hors ligne ou immuable ;
• zéro erreur vérifiée lors des tests de récupération.

Le dernier point est souvent négligé. Une copie immuable mais non restaurable ne protège pas l’activité. Les contrôles automatiques de cohérence et les exercices réguliers de restauration restent obligatoires.

PBS : protection possible, mais architecture à construire

PBS dispose de mécanismes solides de contrôle d’accès, de permissions, de chiffrement côté client et de vérification d’intégrité. Il ne faut cependant pas confondre ces éléments avec une immuabilité native identique à celle d’un dépôt WORM ou d’un bucket S3 avec rétention verrouillée.

Dans un déploiement PBS, la protection contre le ransomware repose souvent sur l’isolement du serveur de sauvegarde, la segmentation réseau, la séparation des comptes, des clés de chiffrement correctement conservées, et la réplication vers un second PBS. Cette synchronisation peut constituer une excellente copie hors site, mais elle ne devient réellement résistante à la suppression malveillante que si la cible est administrativement et techniquement séparée.

Une architecture PBS défendable comprend typiquement :

• un PBS local dédié, non joint au domaine bureautique ;
• des comptes distincts entre Proxmox VE et PBS ;
• un accès d’administration limité par réseau et MFA lorsqu’il est disponible dans la chaîne d’accès ;
• une réplication vers un second PBS sur un site distinct ;
• une conservation des clés de chiffrement hors du périmètre administré au quotidien ;
• des droits limités pour les comptes utilisés par les jobs de sauvegarde ;
• des tests de restauration documentés ;
• idéalement, une copie complémentaire vers un stockage disposant d’une véritable fonction WORM ou d’object lock.

PBS peut donc s’inscrire dans une stratégie anti-ransomware sérieuse, mais l’équipe doit concevoir explicitement l’immuabilité et le cloisonnement. Veeam propose des chemins plus standardisés pour cette exigence, notamment dans les environnements qui exploitent déjà du stockage objet ou des repositories Linux dédiés.

Coûts de licence et coûts réels d’exploitation

Comparer uniquement le prix de licence serait trompeur. Il faut inclure le coût du stockage, des serveurs, de l’administration, du support, des tests et du temps nécessaire pour traiter un incident.

PBS est open source et peut être utilisé sans coût de licence logiciel. Proxmox propose toutefois des souscriptions qui donnent accès à des dépôts logiciels entreprise et au support. Dans un environnement de production, cette souscription est généralement justifiée : elle contribue à la maintenance, réduit le risque lié aux mises à jour et apporte un canal d’escalade en cas de problème. Pour aller plus loin, consultez l’état de l’art de Proxmox VE.

Le coût PBS est donc principalement lié à l’infrastructure : serveur, disques, redondance, site secondaire, bande passante, alimentation, supervision et temps d’administration. Pour une PME ou une équipe maîtrisant Linux et Proxmox VE, le rapport coût-fonctionnalité est souvent excellent. Pour aller plus loin, consultez la protection contre les ransomwares.

Veeam implique une licence commerciale dont le modèle dépend du périmètre protégé, des éditions et des composants utilisés. Le budget augmente avec les workloads, les fonctionnalités de restauration avancée, les agents, les services cloud et les besoins de support. En contrepartie, l’entreprise bénéficie d’un produit plus large, particulièrement pertinent si la sauvegarde doit couvrir des technologies diverses.

Le vrai calcul doit intégrer une question simple : combien coûte une heure d’indisponibilité d’un service critique, et combien de temps l’équipe met-elle réellement à le restaurer avec chaque solution ?

Une solution moins chère en licence peut être le meilleur choix si le RTO est compatible avec ses mécanismes de restauration. Inversement, une licence plus coûteuse peut être rationnelle si elle évite de construire et maintenir plusieurs chaînes de sauvegarde distinctes.

Cas d’usage : quand chaque solution s’impose naturellement

PBS s’impose naturellement dans les cas suivants :

• infrastructure majoritairement ou exclusivement basée sur Proxmox VE ;
• besoin de sauvegardes fréquentes de VM et conteneurs avec stockage dédupliqué ;
• équipe à l’aise avec Linux, le réseau et l’administration Proxmox ;
• volonté de conserver une maîtrise forte de l’infrastructure et des coûts ;
• RTO compatible avec une restauration classique de VM ;
• besoin de réplication simple entre deux sites Proxmox ;
• environnement où la standardisation sur un seul écosystème est un objectif assumé.

Veeam s’impose plus naturellement lorsque :

• le parc contient à la fois VMware, Hyper-V et éventuellement des serveurs physiques ;
• l’organisation souhaite une console et des processus de sauvegarde communs à plusieurs plateformes ;
• la restauration instantanée est une exigence pour certains services ;
• les restaurations applicatives granulaires sont fréquentes ou critiques ;
• la stratégie d’immuabilité s’appuie sur des repositories durcis ou du stockage objet verrouillé ;
• la gouvernance exige des fonctions de reporting, de délégation et d’intégration étendues ;
• les équipes ont besoin d’un support éditeur structuré sur une large gamme de scénarios.

Une troisième approche est possible pendant une transition : PBS pour protéger les workloads Proxmox VE et Veeam pour les plateformes historiques. Cette coexistence n’est pas idéale à long terme, car elle multiplie les procédures et les compétences, mais elle peut être rationnelle durant une migration progressive.

Le critère décisif reste la restauration. Avant de retenir une solution, il faut exécuter un test représentatif : restaurer une VM critique, récupérer un fichier, mesurer le débit réel, vérifier l’état applicatif et chronométrer les opérations. Les promesses fonctionnelles importent moins que le RTO réellement obtenu dans votre réseau, avec votre stockage et vos équipes.