Notre client de sauvegarde Windows pour Proxmox Backup Server n'est pas parti de zéro : c'est un fork de proxmoxbackupclient_go, le client en ligne de commande écrit en Go par Tiziano Bacocco (@tizbac). Nous l'avons toujours écrit noir sur blanc, dans le guide comme dans le dépôt.
Tiziano a repéré notre fork. Il nous a écrit pour nous demander l'autorisation de re-merger l'interface graphique dans son dépôt d'origine, débrandée. Notre réponse tient en un mot : oui. Et nous y ajoutons un volume de sauvegarde sur notre infrastructure, pour qu'il puisse tester.
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.
Le travail a commencé : branche nimbusguimerge
Tiziano a ouvert une branche dédiée sur son dépôt pour absorber la GUI. Elle est publique, et le travail d'intégration y est en cours — rien n'est encore fusionné dans la branche principale amont.
tizbac/proxmoxbackupclient_go — branche nimbusguimergeUne 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 :
Un Proxmox Backup Server managé, distant, avec vrai certificat et vraie latence — pas un PBS de laboratoire sur son poste.
Un token API restreint à son datastore, révocable, sans aucun accès aux données d'autres clients.
De quoi éprouver ce qui fait mal en vrai : les gros volumes, la déduplication sur plusieurs passes, une sauvegarde interrompue et reprise.
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.
Ce que ça change pour vous : rien, pour l'instant
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. Le jour où la GUI sera intégrée en amont, nous le dirons ici et nous expliquerons comment les deux dépôts s'articulent.
Une précision utile, tant qu'on parle de binaires : le client est parfois signalé à tort par Windows Defender ou SmartScreen, faute de signature de code. Nous documentons le mécanisme et les vérifications SHA-256 / VirusTotal sur la page faux positif antivirus.
Questions fréquentes
Qui est tizbac et quel est son lien avec le client Windows Nimbus Backup ?
Tiziano Bacocco (tizbac sur GitHub) est l'auteur de proxmoxbackupclient_go, le client Proxmox Backup Server écrit en Go pour Windows, en ligne de commande. Notre client Nimbus Backup est un fork de ce projet : nous y avons ajouté une interface graphique, un service Windows, la planification, les snapshots VSS et le déploiement par fichiers. Le tout reste sous licence GPL-3.0.
Que va-t-il se passer avec la GUI ?
Tiziano nous a demandé l'autorisation de re-merger notre interface graphique dans son dépôt d'origine. Nous avons répondu favorablement, et il a ouvert une branche de travail nommée nimbusguimerge sur github.com/tizbac/proxmoxbackupclient_go. Le travail d'intégration est en cours : rien n'est encore fusionné dans la branche principale amont.
La GUI intégrée en amont portera-t-elle la marque Nimbus ?
Non. Tiziano rétroporte l'interface graphique débrandée : le code de la GUI part en amont, mais la marque Nimbus Backup et son habillage restent chez nous. C'est exactement ce qu'il faut faire — le code sous GPL-3.0 se partage, une marque ne se partage pas. Le projet amont récupère donc une interface graphique générique pour son client Proxmox Backup Server Windows.
Pourquoi mettre un volume de sauvegarde à disposition de l'auteur amont ?
Parce qu'un client de sauvegarde ne se teste pas correctement à vide. Nous ouvrons à Tiziano un datastore de test sur notre infrastructure Proxmox Backup Server, avec un token API dédié, pour qu'il valide le merge contre un vrai serveur managé, distant, avec certificat et latence réelle — et pas seulement contre un PBS de laboratoire sur son poste.
Le fork Nimbus Backup est-il abandonné ?
Non. Nos versions continuent d'être publiées sur github.com/rdemsystems/proxmoxbackupclient_go et rien ne change pour les utilisateurs actuels du client. L'objectif d'une remontée amont est justement d'éviter que les deux bases divergent durablement.
Les deux dépôts
Open Source GPL-3.0 · le projet d'origine et notre fork avec interface graphique
Merci, Tiziano. Sans proxmoxbackupclient_go, il n'y aurait pas de client Windows Nimbus Backup — et sans doute pas de premier backup 1 To d'un serveur Windows en production à raconter.
Un PBS managé pour vos sauvegardes Windows
Le client est open source et gratuit. Ce que nous vendons, c'est la destination : un Proxmox Backup Server hébergé en France, mis à jour et supervisé, prêt à recevoir vos postes et serveurs Windows.