Skip to main content
commvault.com commvault.com

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

Those settings do not work, 128K with bUseUncompSizeForSig do not deduplicate.


 

Out of interest which version are you on? 

The version is: 11.32.56


From what I recall from my MSSQL DBA training years ago, SQL Server backups operate on a point-in-time basis, using the timestamp of the backup's start. These backups run while MSSQL is actively processing transactions. When MSSQL needs to update a block that hasn’t yet been backed up, the backup process captures that block before being ovewritten and includes it in the backup stream.
 

For example, the block size in cloud storage is by default 512 KB, whereas MSSQL uses 64 KB blocks. During the backup, MSSQL streams data in 64 KB chunks. If MSSQL simultaneously updates a block—say, block 15—the backup stream will include the non-backed up block of data. The resulting 512 KB block in the backup might look something like this: :1]c2]e3]14]215]<5]p6]>7].


In a subsequent backup, the 512 KB block might look different, such as s1]c2]eXX]<3]p4]>5]36]47], even if blocks 1 through 8 remained unchanged between backups. This discrepancy occurs because the backup's data signatures are based on the block structure at the time of each backup, leading to differences despite unchanged underlying data.


When performing backups using VSS, the snapshot is created at the OS level, and the blocks are always found in the same order despite using 64K or 512K dedup block size.

Reply


Terms & ConditionsCookie settings