Skip to main content

Hi,

I am running Commvault with MSSQL, but these backups do not deduplicate; the only savings we get are from compression. None of our MSSQL backups deduplicate at all (+200 DB Clients), we made sure we did not have anything affecting deduplication, like db side encryption etc.

If you run a Commvault backup, and then run another one after the previous has finished on a system with no activity, we would expect 99% dedup savings, but instead of that we have between 50% to 70% cause it is only compressing and the new compressed data has new signatures every time.
 

Our workaround is to use VSS, that works as a file backup, The MSSQL backup with VSS enabled deduplicate with almost 99.9% savings doing the same test. VSS also comes with its own problems like slow backup performance and MSSQL with VSS is not considered best practice for Commvault.


We have over 200 Commvalt clients with MSSQL, and this happens to all of them, we have all with VSS enabled


I opened a ticket in November 2022 and it was closed with a CMR 380741 after the ack the issue. That CMR is intended to use smaller dedup sizes to match the MSSQL block size (64K), onthe same DDB database, without affecting other kind of backups (Oracle/FS etc), but that CMR it hasn't progressed because not many people have noticed or reported the issue. Commvault claims the CMR is an enhancement, but in reality, it's a bug or bad design, as Commvault is unable to deduplicate MSSQL using their guides and best practices.

Has anyone else noticed the same issue? if you had, and If it’s affecting the efficiency of your backups, report it to Commvault support, so they can work on the defnite fix.
 

Regards,
Carlos

Hello Carlos,

 

Looking a the ticket that was closed i can see that was a chat about changing the block size on the pool to 128KB and the key “bUseUncompSizeForSig” was going to be used.

Can you advise if this had a positive effect on the dedup rate and performance?

 

Kind regards

Albert Williams


Reply