Hi,
if you do not set compression, compaction and vol-dedup on the DST, they by default retained as-is on the DST regardless for your snapshot policies (that's given that the baseline was initiated after they all run and completed on the SRC).
As for AGGR level dedup, that's not saved (and also not supported for HDD systems). But I don't really know if you can run it separately on the DST (seems that you can on DPO systems, but that's the only place I've seen it mentioned).
https://www.netapp.com/us/media/tr-4476.pdf
snapmirror:
"Both compression and deduplication are supported with volume SnapMirror.Volume SnapMirror operates at the physical block level. Thus, when deduplication is enabled on the source, the data sent over the wire for replication remains deduplicated, and the savings are inherited at the destination. For compression, storage efficiency is preserved or lost during replication,depending on the following configuration:
•Source and destination volumes use the same compression type (either adaptive or secondary):
Logical replication with storage efficiency is used.Storage efficiency (compressed and deduplicated blocks) is preserved during data transfer"
"Regardless of whether the source system supports data compaction, the data on the destination is compacted on the data compaction supported destination system."
snapvault:
"If you require compression savings on the destination and your source has compression enabled, then do not enable compression on the SnapVault destination. The savings are already inherited on the destination"
"As a best practice, if deduplication is enabled on the source, enable only deduplication on the SnapVault destination if you expect SnapVault updates to occur from Snapshot copies created before deduplication completes on the source. "
"Regardless of whether the source system supports data compaction, the data on the destination is compacted on the data compaction supported destination system."
