Quadstor VTL (extended with deduplication) with Proxmox Backup Server - Experiences?

syned

New Member
Apr 10, 2026
3
0
1
Hello Proxmox Community,


I'm currently running a virtual tape library (Quadstor VTL, extended with deduplication) in my homelab, primarily for personal use with Bacula. I'm now looking into expanding my backup solution, or potentially migrating, to Proxmox Backup Server (PBS).


I'm aware that Quadstor has ceased public distribution of their VTL software, but I'm still using version 3.0.79.15 on Debian 12 in my homelab setup.


I'm keen to hear from anyone who still uses Quadstor VTL (especially the extended version with deduplication). Do you have any experiences to share regarding its compatibility, integration, or performance when used alongside Proxmox Backup Server? Or perhaps insights on migrating data or configuring a similar setup with PBS?


Any feedback or shared experiences would be greatly appreciated as I plan my next steps.


Thanks in advance!
 
Hi,

What would you like to do? PBS has its own chunk-based deduplication and compression built in, and it's quite effective for VM backups specifically. Quadstor's dedup is block-level and more general purpose. If your primary workload is Proxmox VM/CT backups, PBS built in deduplication will likely serve you better. For general file/bare-metal backups via Bacula, Quadstor still makes sense. But if you're already using PBS adding deduplicating VTL would be a kind of overcomplication.
 
  • Like
Reactions: Johannes S
Thanks for the feedback!

You’re totally right about the 'dedup on top of dedup' thing for VMs. But my setup is a legacy hybrid: I’ve been using Bacula for years for all my bare-metal and cross-platform file backups. Since I can’t use PBS as a native target for Bacula, the Quadstor VTL is my bridge to keep those workflows alive on my DL360e while still getting the block-level dedup.

Currently running 3.0.79.15 on Debian 12. Since the public downloads are gone, I was mainly wondering if anyone here still uses the last public builds mentioned in the tutorials for quadstor-vtl-ext I found here on Proxmox forum.

My 'offline' strategy is also a point: I only fire up the server during solar peak hours to keep it cost-neutral and air-gapped most of the time. The VTL/Tape logic just fits that workflow perfectly.

I'm already running PVE 9, but I'm still trying to figure out if I should bring PBS into the mix or stick with my current VTL/Bacula setup for everything. I'd love to hear from anyone who actually implemented those VTL tutorials—is it still a viable path for a modern PVE environment?
 
Thanks for the feedback!

You’re totally right about the 'dedup on top of dedup' thing for VMs. But my setup is a legacy hybrid: I’ve been using Bacula for years for all my bare-metal and cross-platform file backups. Since I can’t use PBS as a native target for Bacula, the Quadstor VTL is my bridge to keep those workflows alive on my DL360e while still getting the block-level dedup.

Currently running 3.0.79.15 on Debian 12. Since the public downloads are gone, I was mainly wondering if anyone here still uses the last public builds mentioned in the tutorials for quadstor-vtl-ext I found here on Proxmox forum.

My 'offline' strategy is also a point: I only fire up the server during solar peak hours to keep it cost-neutral and air-gapped most of the time. The VTL/Tape logic just fits that workflow perfectly.

I'm already running PVE 9, but I'm still trying to figure out if I should bring PBS into the mix or stick with my current VTL/Bacula setup for everything. I'd love to hear from anyone who actually implemented those VTL tutorials—is it still a viable path for a modern PVE environment?
I would suggest using pure vanilla pbs - it's efficient, fast and has internal pruning mechanism. It's not a good idea to overcomplicate the backup.
 
  • Like
Reactions: Johannes S
Thanks, but vanilla PBS doesn't fit here. I specifically need to combine bare-metal Bacula with PVE for an automated copy to offline LTO workflow. The VTL acts as the necessary staging layer to bridge the gap between deduplicated storage and physical tape export.