Our Windows backup client for Proxmox Backup Server did not start from scratch: it is a fork of proxmoxbackupclient_go, the command-line client written in Go by Tiziano Bacocco (@tizbac). We have always said so plainly, in the guide as well as in the repository.
Tiziano noticed our fork. He wrote to us asking for permission to merge the graphical interface back into his own repository, de-branded. Our answer is one word long: yes. And we are adding a backup volume on our infrastructure so he can actually test it.
What happened
The upstream project does one thing, and does it well: back up a Windows directory to a PBS datastore, from the command line. On our side, we needed a tool usable by teams who do not live in a terminal. So on top of that foundation we added a graphical interface, a Windows service that survives reboots, internal scheduling, VSS snapshots and, more recently, fully file-driven deployment with Ansible.
That work is published under GPL-3.0, like the original project. The license therefore required no permission from us for the upstream author to take the code back: he could have done it without asking. He asked anyway. That is a courtesy worth pointing out, and it deserved an equally clear answer: help yourself, and tell us what you need.
Work has started: the nimbusguimerge branch
Tiziano opened a dedicated branch on his repository to absorb the GUI. It is public, and integration work is under way there — nothing has landed in the upstream main branch yet.
tizbac/proxmoxbackupclient_go — nimbusguimerge branchThe GUI is being backported de-branded
An important detail, and the right way to do it: Tiziano is backporting the graphical interface de-branded. The GUI code goes upstream; the Nimbus Backup name and visual identity stay with us. The original project therefore gets a generic interface for its Windows Proxmox Backup Server client, without our name or our colours — and without leading its users to believe they are installing an RDEM Systems product.
The distinction is a simple one: GPL-3.0 code is meant to be shared, a trademark is not. We did not ask for this; he did it on his own, and that is what makes the whole thing healthy on both sides.
We are giving him a backup volume on our infrastructure
A backup client cannot be tested against nothing. Merging a graphical interface into a PBS client means touching the TLS connection, the certificate fingerprint, API tokens, namespaces, chunking and failure recovery — all of which behave differently against a remote server than they do locally.
So we are giving Tiziano a dedicated test datastore on our NimbusBackup infrastructure, with its own API token, so he can validate his merge under real conditions:
A managed, remote Proxmox Backup Server with a real certificate and real latency — not a lab PBS on his own machine.
An API token scoped to his datastore, revocable, with no access whatsoever to other customers' data.
Enough room to stress what actually hurts: large volumes, deduplication across several runs, an interrupted and resumed backup.
Nothing is attached to that access: no exclusivity, no say over the code, no logo to display. It is a test account for a maintainer taking code we wrote back into his own project.
Why we would rather see this code go upstream
A fork left to live its own life eventually drifts, and the community ends up with two half-maintained clients, two sets of bugs and two sets of documentation. We have nothing to gain from that: our business is not selling Windows backup software, it is running the infrastructure that receives those backups. The better and the more widely adopted the client is — whichever repository hosts it — the better off we are.
It is the same logic as our other contributions: when a fix belongs upstream, it goes upstream. We document those, including a BGP fix accepted and backported into FRRouting, on the RDEM Systems open source contributions page.
What changes for you: nothing, for now
If you already use the Nimbus Backup client, nothing moves. Releases keep shipping from our repository, the license stays GPL-3.0, and the Windows binaries stay in the same place. Once the GUI is integrated upstream, we will say so here and explain how the two repositories fit together.
One useful note while we are on the subject of binaries: the client is sometimes wrongly flagged by Windows Defender or SmartScreen, for lack of code signing. We document the mechanism and the SHA-256 / VirusTotal checks on our antivirus false positive page.
Frequently asked questions
Who is tizbac, and how does he relate to the Nimbus Backup Windows client?
Tiziano Bacocco (tizbac on GitHub) is the author of proxmoxbackupclient_go, the command-line Proxmox Backup Server client for Windows written in Go. Our Nimbus Backup client is a fork of that project: we added a graphical interface, a Windows service, scheduling, VSS snapshots and file-driven deployment. Everything stays under the GPL-3.0 license.
What is going to happen to the GUI?
Tiziano asked us for permission to merge our graphical interface back into his original repository. We answered yes, and he opened a working branch called nimbusguimerge on github.com/tizbac/proxmoxbackupclient_go. Integration work is in progress: nothing has been merged into the upstream main branch yet.
Will the upstream GUI carry the Nimbus brand?
No. Tiziano is backporting the graphical interface de-branded: the GUI code goes upstream, but the Nimbus Backup name and visual identity stay with us. That is exactly the right split — GPL-3.0 code is meant to be shared, a trademark is not. The upstream project therefore gets a generic graphical interface for its Windows Proxmox Backup Server client.
Why give the upstream author a backup volume?
Because a backup client cannot be tested properly against nothing. We are opening a dedicated test datastore on our Proxmox Backup Server infrastructure for Tiziano, with its own API token, so he can validate the merge against a real managed remote server — with a real certificate and real latency — instead of only a lab PBS on his own machine.
Is the Nimbus Backup fork being abandoned?
No. Releases keep shipping on github.com/rdemsystems/proxmoxbackupclient_go and nothing changes for current users of the client. The whole point of going upstream is precisely to avoid the two codebases drifting apart for good.
Both repositories
Open Source GPL-3.0 · the original project and our fork with the graphical interface
Thank you, Tiziano. Without proxmoxbackupclient_go there would be no Nimbus Backup Windows client — and probably no first 1 TB production backup of a Windows server to write about.
A managed PBS for your Windows backups
The client is open source and free. What we sell is the destination: a Proxmox Backup Server hosted in France, kept updated and monitored, ready to receive your Windows workstations and servers.