Benchmark Proxmox Backup Server vs. Veeam Agent

[dnehring]

Hi,

we made a small comparison of the backup performance of Promox Backup vs. a local installed Veeam Agent 4. This backup should not be considered as completed nor as general valid for all setups.

Veeam Agent 4.0: Veeam Backup Server 10.x, Storage-VM with Linux and XFS filesystem (Veeam supports data block sharing with the reflink feature)
Proxmox Server, storage with 37 VMs, about 1,5 TiB usage, 25.09 deduplication factor

I benchmarked a single VM (Windows 2019, Exchange 2019 and Fileserver). This VM is IO bounded, about 700 GiB capacity.

Veeam backup agent:
Read: 47.6 GB + 69.5 GB + 1.3 GB (3 disks)
Saved: 53,2 GB
After compression and deduplication: 15,0 GB (on disk!)
Time 8 min. for backup, 46min. for backup point merging

Proxmox backup server:
Send to backup server: 79.8 GB + 30.2 GB + 0.9 GB
After compression: 67.8 GB + 23.2 GB + 0.4 GB
Time: 16 min for everything

Conclusion: Proxmox Backup seems to be much faster, but Veeam seems to have better storage efficience. It would be great if we will see here more enhancements in the future.

Any comments?

One suggestion: in the job logs of proxmox you will see the storage usage (new chunks, compression, etc.) It would be great to save these information in every snapshot to get a better overview how the storage is used. It is clear that the reusage of existing chunks cannot be accounted (deduplication), but no product is doing this technically correctly.

Dirk

 

[chriss]

I do work at a Veeam / Hyper-V Shop. Backup Repos are always ReFS. The merging is blazing fast.

@dnehring do I get it right: your backup repo is a Linux machine with XFS and reflink? So the merging should be as fast as ReFS. What are your settings for the Veeam Job? Inremental forever? Syntethic Fulls? Pls provide a screenshots of the settings, so even unasked questions would be answered

Veeam does only dedup on Backupy _Copy_ Jobs. I did not figure out yet, how dedup with PBS works.

 

[dnehring]

I do work at a Veeam / Hyper-V Shop. Backup Repos are always ReFS. The merging is blazing fast.

@dnehring do I get it right: your backup repo is a Linux machine with XFS and reflink? So the merging should be as fast as ReFS. What are your settings for the Veeam Job? Inremental forever? Syntethic Fulls? Pls provide a screenshots of the settings, so even unasked questions would be answered

Veeam does only dedup on Backupy _Copy_ Jobs. I did not figure out yet, how dedup with PBS works.

Yes, Linux+XFS (reflink) can be primary storage. Look at the attachments. I have a lot of experience with Veeam, merging under Linux (XFS) is faster than ReFS on the same HW (but it takes also some time). I am very suprised that veeam does only dedup on copy jobs. Can you explain me the dedup rate in the agent screenshot I provided? You can see a dedup factor of 1.3!
Nevertheless, I do not want to talk about veeam, this is the proxmox forum. I like to discuss about the backup solution from proxmox, which is a great solution since we do not need any agents!

 

[chriss]

dedup does indeed occur with backup jobs also on veeam. Sorry for my mistake.

@dnehring did you have time do benchmark again with VBR 11 and VAW 5 and hardened Linux repo? Did it change anything regarding the comparison to PBS?

It did learn, that incremental backups with PBS only occur if the VM is constantly running, changed block are stored in memory: https://forum.proxmox.com/threads/b...o-enable-incremental.72843/page-2#post-362483

 

[fabian]

dedup does indeed occur with backup jobs also on veeam. Sorry for my mistake.

@dnehring did you have time do benchmark again with VBR 11 and VAW 5 and hardened Linux repo? Did it change anything regarding the comparison to PBS?

It did learn, that incremental backups with PBS only occur if the VM is constantly running, changed block are stored in memory: https://forum.proxmox.com/threads/b...o-enable-incremental.72843/page-2#post-362483

FAST incremental backups will only happen if the VM has a valid bitmap representing the delta from the last backup snapshot. if a previous backup exists, the new snapshot will always be incremental - it's just that calculcating the delta is more expensive without the bitmap.