2009-06-23 01:03 PM
Depends on the flavor of SnapMirror.
For Volume SnapMirror, you only need to run it on the source as it comes over the wire and is written pre-deduped.
For Qtree SnapMirror, the data is rehydrated on the destination so data would have to be re-deduped on the other side.
2009-06-23 01:16 PM
Pardon my english . let me to rephrase you :
For Volume Snapmirror data transferred compressed so less traffic needed ?
For Qtree same regular traffic transferred without deduplication and i need to enable dedup on both source and destination?
2009-06-23 01:28 PM
Yes. You will typically transfer less traffic with Volume SnapMirror and deduplication because Volume SnapMirror is a physical image transfer so all of the deduplication stays intact across the transfer. Qtree SnapMirror is a logical replication so dedped data is un-deduped, then sent across the wire and is written un-deduped to the destintaion (it stays deduped on the source, of course). So the data would have to re-deduped on the destination in the case of Qtree SnapMirror.
Hope this helps.
2009-06-24 08:24 PM
Just one note that as of 7.3 qtree SnapMirror does support dedup....
2010-11-12 12:47 PM
Quick question, in 7.3 and later, the online backup guide mentions that metadata is placed at the aggregate level and therefore is not replicated alongside a volume snapmirror. I found this reference in a 7.3 ONline Backup Manual. With this in mind, it sounds like a volume snapmirror rehydrates prior to replication. The reason I say this is that I'm troubleshooting an issue at a customer site where the snapmirror operations is many times larger then the size of the snapshots that should be replicating across.
Any insight on my interpretation or the discrepancy between space consumed in snapshots and what is snapmirrored I'd appreciate it. Both platforms are 7.3.2.