Hi Chris,

thank again for your detailed answer.

That’s what I wanted to know

Regards, Wolfgang

Hi @Wolfgang,

Not 100% sure I understand the question, however, running a DDB verification will ensure the data is ‘correctly stored’ on the disk library. 

It’s important to run DDB verification frequently because data can be initially stored in a readable state, however can become corrupted over time (hardware faults / ransomware / malware etc).

Running a DDB Verification will cross-verify the unique data blocks on disk with the information contained in the DDB and the CommServe database. Verifying deduplicated data ensures that all jobs that are written as unique data blocks to the storage media are valid for restore or Auxiliary Copy operations.
 

The jobs containing invalid data blocks are marked with the Failed status. These invalid unique data blocks will not be referenced by the subsequent jobs. As a result, new baseline data for the invalid unique data blocks is written to the storage media.

More info is here: https://documentation.commvault.com/2023e/expert/verification_of_deduplicated_data.html

Hopefully this helps, let me know if not or if I’ve misunderstood.

Regards,

Chris 

Hi Chris,

thank you for your reply.

My question was what happens in the moment of writing data to the library. In the meanwhile we discussed this issue internally. Our conclusion is:

Major issue like NAS share offline are detected by Commvault, of course. But corruption or storage failing issues while new writes are still possible are not identified and CV will not be able to identify corruption on existing chunks. Commvault will not validate or perform CRC checks of existing chunks during backups.

Do you agree to these findings?

Wolfgang

Hi @Wolfgang 

Correct, we do not do a Data Verification whilst we’re backing the data up to storage… this is primarily because of how slow this process would make the actual backup. 

If the media is accessible (regardless of if it’s corrupted or not) at the time we’re laying the data down, then we can probably back up to it, only once the backup is completed will we then be able to ‘verify’ it’s readable to us (commvault) via a data verification operation.
 

Additionally, we do get confirmation from the hardware that the chunk is written successfully, just not that it’s stored properly or ‘readable’ during the backup process… how it is stored is up to the hardware - not Commvault. Once the handover to the hardware is made we have no way of knowing if the HARDWARE  laid down the data correctly.

Hopefully that answers your question.

Regards,

Chris