Transform performance with deduplicating backup storage

[jcorbin121]

I am on V6. Have been testing since mid December and each week it seems the synthetic full transforms get significantly longer on some jobs, anywhere from 5 hours to 19 hours and still going. Is this a known issue? I am using a Quantum DXI8500 as my target, its got plenty of horsepower, and 4 etherchanneled 1GB copper to a Cisco 4500 switch that the ESXi cluster (holding the VM's running Veeam and the backup sources) & the DXiI are connected to - I see a consistant 300-450MB of traffic on those links (and there a couple backups still running). Is there some other way to optimize the transforms? I can run synthetic fulls with Commvault and the transforms are not an issue, but there is a client agent, its slower (not 19 hours slow), and more trouble to manage...

Thanks for any advice

John

[Gostev]

Hi John,

Yes, this is a known issue with deduplicating storage. Transform is very I/O intensive operation (and it is random I/O), while these devices are designed primarily for archival, and thus are not capable of providing good IOPS. We do not recommend leveraging backup modes with transform against deduplicating backup storage, this feature is designed for raw disk storage.

Thanks!