[PVE-User] Proxmox Backup Server (beta)

Roland devzero at web.de
Fri Jul 10 19:31:10 CEST 2020

works like a charm.

2 seconds for finishing an incremental backup job. works with qcow2,
works with zvol. (did not test restore yet)

I'm impressed.  congratulations!


INFO: starting new backup job: vzdump 101 --node pve1.local --storage
pbs.local --quiet 1 --mailnotification always --all 0 --compress zstd
--mode snapshot
INFO: Starting Backup of VM 101 (qemu)
INFO: Backup started at 2020-07-10 19:16:03
INFO: status = running
INFO: VM Name: grafana.local
INFO: include disk 'scsi0' 'local-zfs-files:101/vm-101-disk-0.qcow2' 20G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating Proxmox Backup Server archive 'vm/101/2020-07-10T17:16:03Z'
INFO: issuing guest-agent 'fs-freeze' command
INFO: issuing guest-agent 'fs-thaw' command
INFO: started backup task '5a0a0ef3-2802-42e0-acc3-06147ad1549f'
INFO: resuming VM again
INFO: using fast incremental mode (dirty-bitmap), 48.0 MiB dirty of 20.0
GiB total
INFO: status: 100% (48.0 MiB of 48.0 MiB), duration 1, read: 48.0 MiB/s,
write: 48.0 MiB/s
INFO: backup was done incrementally, reused 19.95 GiB (99%)
INFO: transferred 48.00 MiB in 1 seconds (48.0 MiB/s)
INFO: run: /usr/bin/proxmox-backup-client prune vm/101 --quiet 1
--keep-last 2 --repository root at pam@
INFO: vm/101/2020-07-10T17:13:29Z Fri Jul 10 19:13:29 2020 remove
INFO: Finished Backup of VM 101 (00:00:02)
INFO: Backup finished at 2020-07-10 19:16:05
INFO: Backup job finished successfully

Am 10.07.20 um 16:46 schrieb Roland:
> wo this is great to hear, thanks !
> Am 10.07.20 um 16:15 schrieb Thomas Lamprecht:
>> On 10.07.20 16:06, Roland wrote:
>>> i think there may be a misunderstanding here or i was not clear enough
>>> to express what i meant.
>>> i guess in terms of backup storage,  pbs is doing similar to what
>>> borgbackup does - so indeed that IS i/o and storage effient , but that
>>> refers to the backup target side.
>>> but what about the backup source?
>>> I was referring to VMware cbt as that is a means of avoiding I/O on the
>>> VM storage, i.e. the backup source.
>>> afaik, proxmox/kvm does not (yet) have something like that !?
>> Proxmox Backup Server and Proxmox VE supports tracking what changed with
>> dirty-bitmaps, this avoids reading anything from the storage and sending
>> anything over the network that has not changed.
>>> I you have lot's of terabytes of VM disks, each incremental backup run
>>> will hog the VMs storage (the same like full backup).
>>> In VMware, this is adressed with "changed block tracking", as a backup
>>> agent can determine which blocks of a VMs disks have changed between
>>> incremental backups, so it won't need to scan through the whole VMs
>>> disks on each differential/incremental backup run.
>> see above, we effectively support both - deduplication to reduce target
>> storage impact and incremental backups to reduce source storage and
>> network impact.
>> https://pbs.proxmox.com/docs/introduction.html#main-features
>>> see:
>>> https://kb.vmware.com/s/article/1020128
>>> https://helpcenter.veeam.com/docs/backup/vsphere/changed_block_tracking.html?ver=100
>>> i don't want to criticize proxmox, i think proxmox is fantastic, i just
>>> want to know what we get ( and what we don't get).
>> No worries, no offense taken ;)
>> cheers,
>> Thomas

More information about the pve-user mailing list