You are looking for this?

https://documentation.commvault.com/2023/essential/158314_configuring_data_domain_boost_storage_library.html

DD Boost integration is nothing new, exists since older data domain solutions.

I expect this is a marketing based news item, unless I am interpreting the functionality incorrectly which they are talking about..

It’s not just marketing….it’s huge…no more CIFS/NFS mounts.

Phase 2 and 3 are coming out soon and it brings even more integration benefits.

Correct, but via BoostFS not direct ddboost. 

It’s not just marketing….it’s huge…no more CIFS/NFS mounts.

Phase 2 and 3 are coming out soon and it brings even more integration benefits.

Nice. Thanks. 

According:

Best Practices for Data Domain Boost Access

When using the Data Domain Boost Access library, we recommend to use Commvault deduplication and compression with backups. Keep all of the Commvault data being written in the same format to maximize the space savings provided by the device level deduplication of the Data Domain.

Writing already deduplicated and compressed data to DataDomain? Why? Good practice for all deduplication appliances was to disable CV dedup and compression. 

You are looking for this?

https://documentation.commvault.com/2023/essential/158314_configuring_data_domain_boost_storage_library.html

DD Boost integration is nothing new, exists since older data domain solutions.

Correct, but via BoostFS not direct ddboost. 

 

It’s not just marketing….it’s huge…no more CIFS/NFS mounts.

Phase 2 and 3 are coming out soon and it brings even more integration benefits.

Nice. Thanks. 

Very interested to see what will be introduced during each phase.
Thanks for the clarification :)

According:

Best Practices for Data Domain Boost Access

 

When using the Data Domain Boost Access library, we recommend to use Commvault deduplication and compression with backups. Keep all of the Commvault data being written in the same format to maximize the space savings provided by the device level deduplication of the Data Domain.

 

Writing already deduplicated and compressed data to DataDomain? Why? Good practice for all deduplication appliances was to disable CV dedup and compression. 

I would personally prefer to allocate data with CV dedup and compression looking at the advantages regarding load and savings.
But for this specific product it would not make sense to me, if you you are using for example, the malware scan and the secured vSphere environment to validate if backups are clean.

Hi There,

there is also an article availalbe from DELLEMC now .

Data Domain DDBoostFS Plug-In Application Validation and Best Practices for Commvault Simpana v10, v11.

https://www.dell.com/support/kbdoc/de-de/000206561/data-domain-ddboostfs-plug-in-application-validation-and-best-practices-for-commvault-simpana-v10-v11

a major difference that the commvault document is 

Under the Advanced tab, Uncheck the “Enabled software compression on clients” checkbox to disable Commvault compression as a best practice when using with BoostFS.

Best Practices – Commvault Simpana
1. Disable software compression and encryption for better datadeduplication
2. Enable multiple streams for greater throughput
3. Up to 63 streams per BoostFS

Additional settings to check 

1. Storage Policy copy properties of Primary Global ->Data paths->Data Path Properties ->Block size should be set to 512kb

@lborek i also share the point that a Commvault DDB should not be utilized 

This Dell article is a bit outdated as still mentions Simpana and v10. We are in 2023 not in 2013.

After the 11.32 release the documentation now provides additional info about this new integration, let’s have a look at it!!

https://documentation.commvault.com/2023e/essential/158234_data_domain_boost_storage_library.html

From June 2023: https://infohub.delltechnologies.com/t/dell-powerprotect-dd-series-appliances-and-commvault-integration/ 

/Rubeck