For years, Proxmox Backup Server (PBS) has earned a reputation as one of the most practical parts of the Proxmox stack: fast incremental backups, global deduplication, integrity checks, encryption options, and a workflow that feels designed by people who actually run servers. In Linux-heavy environments, it’s been a straightforward win for protecting Proxmox VE workloads and Linux hosts.
But there has always been one glaring gap: a native Windows client that can back up full Windows machines—physical or virtual—without awkward workarounds. In mixed environments (which is… most environments), Windows isn’t a side quest. It’s still everywhere: line-of-business apps, file servers, domain controllers, legacy workloads, remote office boxes, and plenty of “one VM that can’t be touched.”
Now, a third-party project has started to move that needle: tizbac/proxmoxbackupclient_go, an alpha-quality PBS client written in Go and explicitly aimed at Windows compatibility. It’s not an official Proxmox component, it comes with strong caveats, and it’s not ready to replace mature commercial Windows agents. But it introduces something many admins have been asking for for a long time: the early foundations of “full-machine live backup” using VSS snapshots.
Why Windows has been the missing piece
PBS has long had an official client focused on Linux workflows. The community has repeatedly asked about Windows support, and Proxmox staff have historically been clear: there was no official Windows client. One common workaround was to mount Windows shares via SMB on a Linux host and back up those directories with proxmox-backup-client. That can be workable for certain file backup cases, but it doesn’t solve the big pain points:
- consistent snapshots of open files and system volumes
- whole-machine backups that can be restored reliably
- Windows-specific metadata (permissions, security descriptors)
- a clean operational story for “backup + restore” in Windows land
That’s why a native approach matters. A Windows-aware client can use VSS (Volume Shadow Copy Service) for consistent snapshots, support disk-level workflows, and avoid the “Linux middleware” layer that often complicates troubleshooting.
What this Go client actually does today
The repository describes itself plainly: “a proxmox backup client written in golang, aimed at windows compatibility.” It also leads with a blunt warning: it’s alpha quality and the author takes no responsibility for damage or data loss. That isn’t legal fluff—it’s a signal about maturity.
Even so, the project already covers two useful modes:
1) Directory backups to PBS (API token + standard parameters)
The client can back up a directory to PBS using familiar inputs: PBS base URL, certificate fingerprint, API token auth ID, secret, datastore, namespace, and optional backup ID. There’s also a JSON config option for job definition—handy if you want to standardize tasks across machines.
It also includes basic email notifications via Go templates (subject/body), with fields like number of new chunks, reused chunks, duration, and status.
2) Stream backups (pipe anything into PBS dedup)
A “stream backup” mode lets you back up a stream rather than a PXAR directory archive. That opens useful sysadmin patterns:
mysqldump db | proxmoxbackupgo -backupstream db.sql …- piping generated artifacts for dedup-aware storage
- potentially creating image-based backups from other tooling (the README even hints at future ideas like piping DISM/WIM workflows)
In practical terms, stream mode matters because it can keep dedup benefits even when the payload isn’t a neat filesystem tree.
The headline feature: “full-machine live backup” with VSS
The most interesting addition is the NEW “full machine live backup” feature for Windows 10/11 and Windows Server variants—designed to capture a full system without downtime.
The flow described in the README is roughly:
- point the tool at a physical disk device (example:
\\.\PhysicalDisk0) - detect mounted partitions
- take VSS snapshots
- build a bootable full-disk backup image (as FIDX)
- subsequent runs become incremental; hashing is parallelized for speed
That’s a big deal conceptually: it’s an attempt to bring PBS-style efficiency to Windows “whole machine” backups in a way admins recognize from other enterprise backup products—while still feeding into PBS’s dedup architecture.
The project claims that with parallel hashing, speeds around 1 GB/s can be achievable in good conditions. That’s not a guarantee and shouldn’t be read like a benchmark result you can bank on—but it shows the intent: this isn’t meant to be a slow “copy a giant file” approach.
Where it’s still rough: restores and operational polish
Backups are only half the story. Restores are where tools live or die, and the README is transparent about current limitations:
- File-level restore: not available yet, but planned (the idea is to mark backups differently so they can be treated more like VM backups for browsing/restore).
- Restore to physical machine (current): download the FIDX image from the PBS UI (the whole image) and restore with
dd. - Restore to physical machine (future plan): a Live CD/PXE boot flow that logs into PBS and launches Clonezilla, potentially with deeper integration using a patched QEMU PBS driver to expose the backup efficiently.
That roadmap is interesting, but today’s reality is “it works, but you’ll sweat during restore.” For production, that’s the critical gap.
Performance caveats and known issues
The project calls out practical issues that sysadmins will immediately relate to:
- Windows Defender can reduce performance by up to 25% (as stated in the README).
- There’s caution around multiple instances running at once (VSS conflicts can ruin your day). The author suggests Windows Task Scheduler can help prevent overlap if jobs are configured properly.
It also lists a set of contributions it actively wants: GUI/tray progress, encryption support, async upload/compression, Windows security descriptor handling in PXAR, and symlink support. These requests are telling: they map to exactly what Windows admins will demand before they trust a backup agent.
What this means for the Proxmox ecosystem
This project doesn’t instantly “solve Windows for PBS.” But it does something important: it proves that the missing client problem is being tackled with real engineering—starting with the hardest part (consistent live snapshots and full-machine capture).
For Proxmox shops that want a unified backup backend, a workable Windows client could simplify strategy dramatically: fewer products, a single retention/dedup model, and consistent operational habits across Linux and Windows fleets.
The responsible stance right now is cautious optimism:
- test it in labs
- validate restores, not just backups
- treat the alpha warning as real
- don’t confuse “it ran once” with “it’s ready for RPO/RTO commitments”
Still, for a community that has wanted “PBS, but for Windows too,” this is the first time in a while that the answer isn’t just a workaround—it’s a real path, even if it’s early.
FAQ
Q: Is there an official Proxmox Backup Server client for Windows?
A: No. Proxmox staff have previously stated that PBS did not have a Windows client, and community workarounds often involved SMB shares backed up from Linux.
Q: What does “full-machine live backup” mean for Windows in this project?
A: It means capturing a whole Windows system disk while the machine is running, using VSS snapshots for consistency, and storing it efficiently in PBS (as described by the project).
Q: Can you restore a Windows machine cleanly today with this tool?
A: Restore is currently rough: it involves downloading the full image and restoring with tools like dd. File-level restore is not available yet, according to the README.
Q: What are the biggest risks of using an alpha backup client in production?
A: The main risk isn’t just a failed backup—it’s discovering during an incident that restore is unreliable or operationally too fragile for your required RPO/RTO.