Total Data to Process vs Back-end Size

The quick full verification will:

Quote: 

“This option validates if the existing backup jobs are valid for restores and can be copied during Auxiliary Copy operations.

In comparison with the Verification of existing jobs on disk and deduplication database option, this option is faster because it does not read the data blocks on the disk. Instead, it ensures that both the DDB and disk are in sync.”

https://documentation.commvault.com/11.24/expert/100399_data_verification_of_deduplicated_data.html

Space reclamation by hole drilling should normally occur automatically in the data aging process if the storage has sparse file support enabled. If hole drilling is not available the complete data chunks will only be aged when not referenced anymore by the DDB. Data aging is by default performed automatically on a daily base. To initiate reclamation manually for storage without sparse file support you can perform the space reclamation process. Advice is to consult support before using this.

https://documentation.commvault.com/11.24/expert/127689_performing_space_reclamation_operation_on_deduplicated_data.html

The amount shown in the DDB verification job is the application size, not the backend size.

In regards to the DDB partitions, I checked and the maximum is 4 by default anything higher will result in this error:

When settings are changed then 6 partitions for a DDB currently is the maximum:

https://documentation.commvault.com/v11/expert/12455_configuring_additional_partitions_for_deduplication_database.html

Quote: "To define the maximum number of allowed DDB partitions, set the Maximum allowed substore configuration parameter to 6. For more information, see Media Management Configuration: Deduplication"

In your example to use 4 nodes it would be logical to divide 4 partitions for 1 DDB over the nodes. So 1 partition per node. You can of course define 6 partitions in total and assign 2 remaining partitions on 2 nodes, but then load will not be balanced evenly over the nodes as 2 nodes will have 1 partition and 2 nodes will have 2 partitions.

Please note that load initially will not be evenly over the nodes as the existing partitions for a DDB already have references to blocks. This cannot be rebalanced to new partitions. Over time it can balance as references are aged in the DDB when the blocks referenced to are aged, but when this is achieved depends on the environment specifics.

A media agent can host multiple DDB's so in this context there would generally be a disk per partition belonging to a DDB. So if your MA is hosting 2 DDB's it can have for example 2 disks (one partition per DDB) or 4 disks (2 partitions per DDB)