Performance issues with SureBackup.

[remko.de.koning]

Hi guys,

I need some help understanding why I am seeing a performance hit on my SureBackups.

My backup files are stored on a 19 TB Volume with data deduplication enabled.

Everything older than 3 days is dedupped.


I use reversed incrementals as my backup method and create once a month a real Full.
My assumption was that if I create a new (synthetic) full each day my last .VBK file is never a dedupped file.
However, when I use SureBackup to test my latest backup I see quite a performance hit. This makes the Surebackup extremly slow.
In the performance monitor I see a lot of disk access on the "chunck store"
Normal disk access should be about 350 MB/s on this volume on a non-dedupped file, while on a dedupped file it drops to approx 40-80 MB/s

The hardware should be more than sufficient for this purpose.
The Virtual Lab is running on the local Veeam Backup Server with the HyperV role installed. The storage volume is made of local disks in a RAID-5 setup.
The backup server itself is a HP Proliant dl380 with 80 GB memory.

Can someone help me understand why my assumption is incorrect? Why is it trying to rehydrate the file? Is there anything I can do to improve performance?

Thanks for any thoughts you might have.

Remko

[Gostev]

Hello,

This is totally expected.

It is pretty much impossible to get good Instant VM Recovery performance from any deduplicating storage. Deduplicating storage vendors like to compare their storage to tapes, so I like to use the same comparison for this scenario as well - you are basically trying to run your VMs from tape. Just like tape, deduplicating storage is optimized for sequential writes and reads - and is very bad with random I/O.

This is why our reference architecture suggests using raw and fast primary backup storage, and only use deduplication on secondary backup storage.

Thanks!

[foggy]

My assumption was that if I create a new (synthetic) full each day my last .VBK file is never a dedupped file.

Does it probably perform deduplication based off the file creation date? In case of reversed incremental mode, changes are being injected into the existing VBK file each day, which is already deduplicated.

[remko.de.koning]

I really cannot think of any other reason as the one you mentioned. I guess my assumption was wrong by thinking that the file was newly created an thus not deduplicated. It works but the performance could be a whole lot better. Also, I need to consider that restores might also take longer than I initially thought.
Back to the drawing board

[foggy]

Just to help you with drawing: What is the ultimate VM backup architecture?