Dedupe works differently within Volume SnapMirror and SnapVault.
In the case of Volume SnapMirror, deduplicated data within the volume is transferred in a deduplicated state resulting in a reduction in network bandwidth utilization, as well as the fact that the destination will inherit the deduplication properties from the primary storage.
The SnapVault approach is different. Following the baseline transfer, SnapVault will only transfer changed blocks to the destination resulting in very thin data transfers. Deduplicated data that is transferred with SnapVault is not deduplicated, but can be deduplicated at the destination site. A SnapVault solution that can yield good savings is when SnapVault is used to transfer data from multiple qtrees from multiple volumes, and even different systems, to a single destination which can be deduplicated.
To properly take advantage of dedup - it was recommended to run 7.3.1 - which has this bug when using NFS volumes in snapvault. I was hoping that this bug would be addressed soon so that we can upgrade to 7.3.1 and start using dedup.
Our concern was that we wanted to run 7.3.1 on our less critical snapvault destination filer first and start looking at dedup - then upgrade our production cluster as well. This bug is our current show stopper. We would love to see dedup in action.