Notre GUI Windows pour PBS a rejoint le projet de tizbac

Ce que la fusion a apporté en amont

Tiziano n'a pas seulement repris l'interface : il a continué à la développer dans son dépôt. D'après l'historique de la branche principale amont, arrêté au 7 septembre 2026, voici ce qui s'y est ajouté par rapport à notre version :

• La sauvegarde de machine entière retravaillée (mode disque) : progression sur l'ensemble du job, annulation réelle, VSS imposé.
• Une documentation réécrite, avec un README décliné en une douzaine de langues.
• Une marque qui se choisit à la construction : l'habillage de l'exécutable et de l'installeur (WiX) est paramétrable. Le code est commun, la marque ne l'est pas — exactement la répartition décrite plus bas.
• Restauration bare-metal : outillage pour construire une ISO de secours WinPE et une ISO Clonezilla capable de lire une sauvegarde sur le PBS.
• Sous Linux, un moteur de snapshots en mode bloc (elastio-snap) pour la sauvegarde de machine entière.
• Des paquets Debian, Arch (PKGBUILD) et Fedora (spec RPM) pour le client Go. À ne pas confondre avec notre dépôt non officiel, qui redistribue le client officiel de Proxmox, écrit en Rust.
• Une construction de la GUI Windows par Docker, pour compiler depuis Linux.

Comment les deux dépôts s'articulent

• tizbac/proxmoxbackupclient_go est le projet de référence : le client en ligne de commande, les outils de sauvegarde de machine, et désormais la GUI, sous une marque générique.
• rdemsystems/NimbusBackupClient est notre distribution sous la marque Nimbus Backup : installeur MSI, service Windows, déploiement par fichiers et rapports VirusTotal publiés pour chaque version. Nous y reportons les évolutions du projet amont : la 0.4.1 (9 octobre 2026) est construite sur la branche principale amont au commit 3c1b989 du 9 octobre, qu'aucune release amont ne contient encore, et intègre notamment le chiffrement côté client développé par Tiziano.
• Attention à la configuration. Les deux versions ne rangent pas leur fichier de configuration au même endroit : passer directement de Nimbus Backup à une version construite depuis le dépôt amont ne reprend pas la configuration existante. Le chemin prévu est de passer d'abord par Nimbus Backup 0.4.0, publiée le 24 septembre 2026 : elle réintègre le code amont, aligne ses dossiers de configuration sur ceux de l'amont et y copie vos fichiers si besoin. Nous proposerons ensuite au projet amont une modification pour que cette copie se fasse aussi lors d'une mise à jour directe, sans passer par la 0.4.0.
• Signature des binaires Windows : les nôtres sont signés depuis la 0.4.1 (Authenticode, via Azure Artifact Signing, certificat au nom de RDEM SYSTEMS) ; la 0.4.0 était sortie sans signature, l'ouverture du compte ayant été bloquée côté Microsoft. Au 9 octobre 2026, la dernière release amont (v1.1.3) ne porte pas de signature Authenticode. Les empreintes SHA-256 et les rapports VirusTotal restent publiés (voir faux positif antivirus).

Le reste de cet article raconte comment tout a commencé, fin juillet.

Ce qui s'est passé

Le projet amont fait une chose, très bien : sauvegarder un répertoire Windows vers un datastore PBS, en ligne de commande. De notre côté, nous avions besoin d'un outil utilisable par des équipes qui ne vivent pas dans un terminal. Nous avons donc ajouté, par-dessus ce socle, une interface graphique, un service Windows qui survit au reboot, la planification interne, les snapshots VSS et, plus récemment, le déploiement entièrement par fichiers via Ansible.

Ce travail est publié sous GPL-3.0, comme le projet d'origine. La licence n'exigeait donc aucune permission de notre part pour que l'auteur amont reprenne le code : il pouvait le faire sans nous demander quoi que ce soit. Il a préféré demander. C'est une élégance qui mérite d'être signalée, et elle appelait une réponse aussi nette : servez-vous, et dites-nous ce dont vous avez besoin.

Une GUI rétroportée débrandée

Précision importante, et c'est la bonne façon de faire : Tiziano rétroporte l'interface graphique débrandée. Le code de la GUI part en amont, la marque Nimbus Backup et son habillage restent chez nous. Le projet d'origine récupère donc une interface générique pour son client Proxmox Backup Server sous Windows, sans notre nom ni nos couleurs — et sans laisser croire à ses utilisateurs qu'ils installent un produit RDEM Systems.

La distinction est simple : du code sous GPL-3.0 se partage, une marque ne se partage pas. Nous n'avons rien demandé sur ce point, il l'a fait de lui-même, et c'est ce qui rend l'opération saine des deux côtés.

Nous lui ouvrons un volume de sauvegarde sur notre infra

Un client de sauvegarde ne se teste pas à vide. Fusionner une interface graphique dans un client PBS, c'est toucher à la connexion TLS, à l'empreinte de certificat, aux tokens API, aux namespaces, au découpage en chunks et à la reprise sur incident. Autant de choses qui se comportent différemment face à un serveur distant qu'en local.

Nous mettons donc à disposition de Tiziano un datastore de test dédié sur notre infrastructure NimbusBackup, avec son propre token API, pour qu'il valide son merge dans les conditions du réel :

Aucune contrepartie n'est attachée à cette mise à disposition : ni exclusivité, ni droit de regard sur le code, ni logo à afficher. C'est un accès de test pour un mainteneur qui reprend du code que nous avons écrit sur le sien.

Pourquoi nous préférons voir ce code remonter amont

Un fork qui vit sa vie finit par diverger, et la communauté se retrouve avec deux clients à moitié maintenus, deux jeux de bugs, deux documentations. Nous n'avons rien à gagner à cette situation : notre métier n'est pas de vendre un logiciel de sauvegarde Windows, c'est d'exploiter l'infrastructure qui reçoit ces sauvegardes. Plus le client est bon et largement adopté — quel que soit le dépôt qui l'héberge —, mieux nous nous portons.

C'est la même logique que nos autres contributions : quand un correctif a du sens en amont, il part en amont. Nous documentons ces remontées, y compris un correctif BGP accepté et backporté dans FRRouting, sur la page contributions open source de RDEM Systems.

Autre partage, côté Linux cette fois : Proxmox ne publie proxmox-backup-client que pour Debian. Nous le republions sans le recompiler, signé, dans un dépôt non officiel pour RHEL, Rocky, Alma, Fedora, Arch et Alpine, avec le guide pour installer Proxmox Backup Client sur une autre distribution Linux.

Ce que ça change pour vous

Si vous utilisez déjà le client Nimbus Backup, rien ne bouge. Les versions continuent d'être publiées sur notre dépôt, la licence reste GPL-3.0, et les binaires Windows restent téléchargeables au même endroit. La GUI est désormais intégrée en amont : l'articulation des deux dépôts est décrite dans la mise à jour du 23 septembre.

Une précision utile, tant qu'on parle de binaires : le client est parfois signalé à tort par Windows Defender ou SmartScreen. La signature, active depuis la 0.4.1, fait apparaître RDEM SYSTEMS comme éditeur vérifié, mais l'avertissement peut subsister tant que la réputation n'est pas établie. Nous documentons le mécanisme et les vérifications (signature, SHA-256, VirusTotal) sur la page faux positif antivirus.

Questions fréquentes