Proxmox a publié Proxmox Backup Server 4.2 le 29 avril 2026, et la liste des changements parle d’elle-même : passage à Debian 13.4 « Trixie », adoption du noyau Linux 7.0 par défaut, intégration de ZFS 2.4.1 et surtout fin du statut « preview » pour le backend S3, qui devient officiellement supporté. Pour les administrateurs qui font tourner du Proxmox VE en production, c’est la première version vraiment alignée sur les besoins multi-sites et multi-stockages.
La sortie ne mise pas sur une fonctionnalité-vitrine. Elle empile une série d’améliorations opérationnelles qui, mises bout à bout, simplifient sérieusement la gestion d’environnements complexes : réorganisation des sauvegardes sans tout reconstruire, chiffrement en transit sur les flux de synchronisation, traitement parallèle multi-groupes et observabilité fine du stockage objet. Autant de chantiers que la communauté demandait depuis plusieurs cycles.
Ce qui change vraiment dans la 4.2
| Domaine | Changement |
|---|---|
| Base système | Debian 13.4 « Trixie » avec paquets et correctifs récents |
| Noyau | Linux 7.0 comme noyau stable par défaut |
| Stockage local | ZFS 2.4.1 pour datastores en environnement professionnel |
| Organisation | Déplacement de groupes et namespaces au sein d’un même datastore |
| Synchronisation push | Chiffrement des snapshots côté serveur avant transfert |
| Synchronisation pull | Déchiffrement de snapshots chiffrés côté distant |
| Performance sync | Propriété worker-threads pour traitement parallèle |
| Stockage objet | S3 passe de preview à backend officiellement supporté |
| Observabilité S3 | Compteurs de requêtes, statistiques de trafic et alertes par seuil |
| Sécurité | Correctifs AppArmor (Crackarmor), élévation Sys.Modify, AuthIP derrière proxy |
Réorganiser les sauvegardes sans tout casser
La nouveauté la plus attendue concerne probablement le déplacement de groupes de sauvegarde et de namespaces à l’intérieur d’un même datastore. Quiconque a hérité d’une infrastructure PBS ayant grandi par à-coups sait à quel point la situation peut devenir confuse : conventions de nommage qui changent, clients absorbés ou renommés, machines déplacées d’un service à l’autre, namespaces créés au fil de l’eau sans plan global.
Jusqu’ici, remettre de l’ordre supposait souvent de reconstruire les sauvegardes ou de jouer du script avec le risque d’incohérences. La 4.2 introduit un déplacement natif qui maintient la cohérence via des verrous par groupe, gère les conflits et reprend automatiquement les opérations partiellement terminées. Concrètement, un administrateur peut enfin classer ses sauvegardes par client, département, criticité ou cycle de vie sans toucher au contenu réel des snapshots.
Le bénéfice n’est pas spectaculaire sur le papier, mais il enlève une friction que les équipes ops de migrations Proxmox récentes rencontrent systématiquement quand elles atteignent le seuil des centaines de VMs.
Synchronisation : chiffrement et parallélisme
La synchronisation entre datastores est l’autre gros chantier de cette version. Les tâches push savent maintenant chiffrer les snapshots côté serveur avant de les expédier vers la destination distante. Pour une équipe IT qui réplique vers un site secondaire, un fournisseur tiers ou un environnement moins maîtrisé, c’est une couche de protection qui manquait clairement, surtout depuis que la conformité RGPD et les politiques de chiffrement-at-rest sont devenues la norme.
Symétriquement, les tâches pull peuvent récupérer et déchiffrer des snapshots qui sont déjà chiffrés sur un stockage distant. La gestion des clés associées, qu’il s’agisse de cryptage pour bande ou pour synchronisation, passe par un tableau de bord centralisé. Ça paraît anodin tant qu’on n’a pas eu à jongler entre cinq fichiers de clés sur trois sites différents.
Côté débit, la propriété worker-threads autorise le traitement parallèle de plusieurs groupes dans une même tâche push ou pull. Sur les liens longs entre datacenters, ou face aux limites bien connues du multiplexage HTTP/2, le gain est mesurable. C’est exactement le type d’optimisation qui distingue une plateforme de backup mature d’une solution qui « marche jusqu’à 50 To et puis voilà ».
S3 enfin officiellement supporté
Le passage du backend S3 du statut « preview » à celui de fonctionnalité officiellement supportée est sans doute le signal le plus fort de cette version. Le stockage objet compatible S3 séduit par son coût au tera, sa scalabilité quasi infinie et la séparation physique qu’il offre par rapport au socle de virtualisation. Mais beaucoup d’équipes hésitaient à pousser des sauvegardes critiques sur un backend marqué expérimental.
Avec la 4.2, Proxmox stabilise la promesse et y ajoute ce qui manquait pour gérer ce stockage en aveugle : compteurs de requêtes, statistiques de trafic, alertes par seuil et reset périodique via tâches planifiées. Le résumé du datastore affiche désormais ces métriques dans l’interface graphique. Pour qui a déjà reçu une facture S3 multipliée par cinq à cause d’un job mal configuré, la valeur de ces garde-fous n’a pas besoin d’être démontrée.
La logique rappelle celle d’autres acteurs qui ont misé sur l’objet pour la sauvegarde, comme on l’a vu avec myQNAPcloud One côté NAS. Le backend S3 de PBS gère aussi automatiquement les erreurs HTTP 500/503/504, réduit les appels aux listings de contenu, prend en charge des proxies HTTP au niveau du nœud et autorise la suppression objet par objet pour les fournisseurs qui ne supportent pas la suppression par lot. C’est dans ce niveau de détail qu’on mesure si une fonctionnalité est prête pour la production.
Sécurité : correctifs ciblés et durcissement
La 4.2 embarque plusieurs correctifs de sécurité méritant attention. Proxmox a notamment fermé une brèche permettant à un utilisateur disposant du privilège Sys.Modify d’injecter des options arbitraires dans une invocation d’apt-get. Une fuite d’information sur l’existence d’utilisateurs dans certains scénarios a été corrigée, ainsi qu’un problème d’authentification par IP quand PBS est déployé derrière un proxy inverse, configuration courante dans les architectures modernes.
Les patchs pour les vulnérabilités AppArmor regroupées sous le nom « Crackarmor » sont également intégrés. Côté robustesse, le comportement face aux fichiers d’état de jobs corrompus ou manquants a changé : au lieu de bloquer l’affichage, l’API renvoie un état inconnu et le proxy peut réparer les fichiers à la prochaine exécution. Un détail, mais qui évite les indisponibilités d’interface au pire moment.
Client et installation : ce qui simplifie le quotidien
Le client de ligne de commande accepte désormais des paramètres dédiés pour définir un dépôt (serveur, port, datastore, auth-id, namespace) comme alternative à l’URL complète. Pour qui scripte ses sauvegardes ou travaille avec plusieurs cibles, cela rend les commandes plus lisibles et plus faciles à templatiser dans Ansible ou un autre outil de configuration management.
Le support des flux FIFO en sauvegarde d’image a été optimisé, le chargement des clés de chiffrement au montage corrigé, et la sélection automatique du snapshot le plus récent en restauration améliorée pour éviter une famille d’erreurs spécifiques. Côté installation, l’assistant proxmox-auto-install-assistant peut maintenant générer des ISOs compatibles PXE et iPXE, à condition que le système hôte dispose d’au moins 6 GiB de mémoire. La nouvelle ISO 4.2-1 a été publiée le 29 avril 2026.
Ce que cela change pour les administrateurs
Pour un DSI ou un administrateur système, cette mise à jour pèse sur trois plans. D’abord la modernisation du socle : Debian Trixie, noyau 7.0 et ZFS 2.4.1 alignent PBS sur l’état de l’art Linux serveur de 2026, avec les bénéfices de compatibilité matérielle et de sécurité que cela implique. Ensuite la réduction de la charge opérationnelle dans les environnements en croissance, où la réorganisation simple des sauvegardes devenait un coût caché. Enfin l’intégration S3 mature, qui ouvre des architectures hybrides crédibles entre stockage local et cloud objet, sujet central pour quiconque repense sa stratégie de protection lors d’une migration d’hyperviseur.
La disponibilité du noyau 7.0 a aussi un effet d’entraînement plus large dans l’écosystème Proxmox. Le projet l’avait déjà publié comme option installable dans les dépôts test et no-subscription pour Proxmox VE 9, en recommandant de rester sur le 6.17 sauf besoin spécifique. Avec la 4.2 du Backup Server, le 7.0 devient la nouvelle valeur par défaut côté sauvegarde, et la suite du cycle Proxmox VE 9 va probablement suivre.
Selon la roadmap officielle, aucune incompatibilité majeure n’est signalée. La procédure standard reste de mise pour quiconque opère en production : lecture attentive des notes de version, test en environnement non critique, validation matérielle, simulation de sauvegardes et de restaurations. Un backup n’est pleinement fiable que lorsqu’il a été restauré avec succès, principe qui rejoint la logique des migrations massives observées chez les acteurs sortis de VMware, comme l’illustre la trajectoire financière récente de Proxmox.
Proxmox Backup Server 4.2 ne change pas la nature du produit. Il en fait une plateforme prête pour des déploiements d’entreprise sérieux, avec synchronisation chiffrée, S3 officiellement supporté, observabilité fine et socle système à jour. C’est ce qui sépare un outil pratique d’une vraie composante de plan de continuité d’activité.
Questions fréquentes
Sur quelle base technique repose Proxmox Backup Server 4.2 ?
La version est construite sur Debian 13.4 « Trixie », adopte le noyau Linux 7.0 comme noyau stable par défaut et intègre ZFS 2.4.1 pour le stockage local.
Que change le passage de S3 en backend officiel ?
Le stockage compatible S3 sort du statut preview. Il bénéficie maintenant de compteurs de requêtes, statistiques de trafic, alertes par seuil et gestion automatique des erreurs HTTP 500, 503 et 504, pour un usage en production maîtrisé.
À quoi sert le déplacement de groupes et de namespaces ?
Il permet de réorganiser les sauvegardes existantes au sein d’un même datastore sans reconstruire, en maintenant la cohérence grâce à des verrous par groupe et à la reprise automatique des opérations interrompues.
Comment fonctionne le chiffrement en synchronisation ?
Les tâches push peuvent chiffrer les snapshots côté serveur avant transfert vers une destination distante, et les tâches pull peuvent récupérer et déchiffrer des snapshots déjà chiffrés sur un stockage tiers.
Quels privilèges et risques de sécurité ont été corrigés ?
Proxmox a fermé une brèche d’injection sur apt-get exploitable avec Sys.Modify, intégré les patchs AppArmor « Crackarmor » et corrigé une fuite d’information sur l’existence d’utilisateurs ainsi qu’un problème d’authentification par IP derrière un proxy inverse.
Source : PBS Roadmap
