Qtree SnapMirror over volume SnapMirror
QSM: Unaffected by disk size or disk checksum differences between the source and destination irrespective of type of volumes used (traditional or flexible)
VSM:Unaffected by disk size or disk checksum differences between the source and destination if flexible volumes are used
Affected by disk size or disk checksum differences between the source and destination if traditional volumes are used
QSM:Destination volume must have free space available equal to approximately 105% of the data being replicated
VSM:Destination volume must be equal or larger than the source volume
QSM:Sensitive to the number of files in a qtree due to the nature of the qtree replication process. The initial phase of scanning the inode file may be longer with larger number of files
VSM:Not sensitive to the number of files in a volume
QSM:Qtree SnapMirror destinations can be placed on the root volume of the destination storage system
VSM:The root volume cannot be used as a destination for volume SnapMirror
QSM: Replicates only one Snapshot copy of the source volume where the qtree resides (the copy created by the SnapMirror software at the time of the transfer) to the destination qtree. Therefore, qtree SnapMirror allows independent Snapshot copies on the source and destination
VSM:Replicates all Snapshot copies on the source volume to the destination volume. Similarly, if a Snapshot copy is deleted on the source system, volume SnapMirror deletes the Snapshot copy at the next update. Therefore volume SnapMirror is typically recommended for disaster recovery scenarios, because the same data exists on both source and destination. Note that the volume SnapMirror destination always keeps an extra SnapMirror Snapshot copy
QSM:A qtree SnapMirror destination volume might contain replicated qtrees from multiple source volumes on one or more systems and might also contain qtrees or non-qtree data not managed by SnapMirror software
VSM:A volume SnapMirror destination volume is always a replica of a single source volume
QSM:Multiple relationships would have to be created to replicate all qtrees in a given volume by using qtree-based replication
VSM:Volume-based replication can take care of this in one relationship (as long as the one volume contains all relevant qtrees)
QSM:For low-bandwidth wide area networks, qtree SnapMirror can be initialized using the LREP tool
VSM:Volume SnapMirror can be initialized using a tape device (SnapMirror to Tape) by using the snapmirror store and snapmirror retrieve commands.
QSM:Qtree SnapMirror can only occur in a single hop. Cascading of mirrors (replicating from a qtree SnapMirror destination to another qtree SnapMirror source) is not supported
VSM: Cascading of mirrors is supported for volume SnapMirror
QSM: Qtree SnapMirror updates are not affected by backup operations. This allows a strategy called continuous backup, in which traditional backup windows are eliminated and tape library investments are fully used.
VSM:Volume SnapMirror updates can occur concurrently with a dump operation of the destination volume to tape by using the dump command or NDMP-based backup tools. However, if the volume SnapMirror update involves a deletion of the Snapshot copy that the dump operation is currently writing to tape, the SnapMirror update will be delayed until the dump operation is complete
QSM:The latest Snapshot copy is used by qtree SnapMirror for future updates if the –s flag is not used
VSM:Volume SnapMirror can use any common Snapshot copy for future updates
QSM: Qtrees in source deduplicated volumes that are replicated with qtree SnapMirror are full size at the destination
Source deduplicated volumes that are replicated with volume SnapMirror remain deduplicated at the destination
Even though the source volume is deduplicated, qtree SnapMirror will expand the data and send the entire data to the destination
VSM:Deduplication savings also extend to the bandwidth savings because volume SnapMirror only transfers unique blocks
QSM:Source and destination volumes can be independently deduplicated
Destination volume is read-only and therefore destination volume cannot be independently deduplicated. If deduplication savings are desired on the destination volume, then the source volume must be deduplicated
QSM: The files in the file system gain new identity (inode numbers etc.) in the destination system. Therefore, file handles cannot be migrated to the destination system
VSM:The files in the file system have the same identity on both source and destination system
QSM: LUN clones can be created on the destination volume, but not in the destination qtree
VSM:LUN clones cannot be created on the destination volume because the volume is read-only. However, LUN clones can be created on a FlexClone volume because the FlexClone volume is writable
QSM: Unaffected by disk size or disk checksum differences between the source and destination irrespective of type of volumes used (traditional or flexible)
VSM:Unaffected by disk size or disk checksum differences between the source and destination if flexible volumes are used
Affected by disk size or disk checksum differences between the source and destination if traditional volumes are used
QSM:Destination volume must have free space available equal to approximately 105% of the data being replicated
VSM:Destination volume must be equal or larger than the source volume
QSM:Sensitive to the number of files in a qtree due to the nature of the qtree replication process. The initial phase of scanning the inode file may be longer with larger number of files
VSM:Not sensitive to the number of files in a volume
QSM:Qtree SnapMirror destinations can be placed on the root volume of the destination storage system
VSM:The root volume cannot be used as a destination for volume SnapMirror
QSM: Replicates only one Snapshot copy of the source volume where the qtree resides (the copy created by the SnapMirror software at the time of the transfer) to the destination qtree. Therefore, qtree SnapMirror allows independent Snapshot copies on the source and destination
VSM:Replicates all Snapshot copies on the source volume to the destination volume. Similarly, if a Snapshot copy is deleted on the source system, volume SnapMirror deletes the Snapshot copy at the next update. Therefore volume SnapMirror is typically recommended for disaster recovery scenarios, because the same data exists on both source and destination. Note that the volume SnapMirror destination always keeps an extra SnapMirror Snapshot copy
QSM:A qtree SnapMirror destination volume might contain replicated qtrees from multiple source volumes on one or more systems and might also contain qtrees or non-qtree data not managed by SnapMirror software
VSM:A volume SnapMirror destination volume is always a replica of a single source volume
QSM:Multiple relationships would have to be created to replicate all qtrees in a given volume by using qtree-based replication
VSM:Volume-based replication can take care of this in one relationship (as long as the one volume contains all relevant qtrees)
QSM:For low-bandwidth wide area networks, qtree SnapMirror can be initialized using the LREP tool
VSM:Volume SnapMirror can be initialized using a tape device (SnapMirror to Tape) by using the snapmirror store and snapmirror retrieve commands.
QSM:Qtree SnapMirror can only occur in a single hop. Cascading of mirrors (replicating from a qtree SnapMirror destination to another qtree SnapMirror source) is not supported
VSM: Cascading of mirrors is supported for volume SnapMirror
QSM: Qtree SnapMirror updates are not affected by backup operations. This allows a strategy called continuous backup, in which traditional backup windows are eliminated and tape library investments are fully used.
VSM:Volume SnapMirror updates can occur concurrently with a dump operation of the destination volume to tape by using the dump command or NDMP-based backup tools. However, if the volume SnapMirror update involves a deletion of the Snapshot copy that the dump operation is currently writing to tape, the SnapMirror update will be delayed until the dump operation is complete
QSM:The latest Snapshot copy is used by qtree SnapMirror for future updates if the –s flag is not used
VSM:Volume SnapMirror can use any common Snapshot copy for future updates
QSM: Qtrees in source deduplicated volumes that are replicated with qtree SnapMirror are full size at the destination
Source deduplicated volumes that are replicated with volume SnapMirror remain deduplicated at the destination
Even though the source volume is deduplicated, qtree SnapMirror will expand the data and send the entire data to the destination
VSM:Deduplication savings also extend to the bandwidth savings because volume SnapMirror only transfers unique blocks
QSM:Source and destination volumes can be independently deduplicated
Destination volume is read-only and therefore destination volume cannot be independently deduplicated. If deduplication savings are desired on the destination volume, then the source volume must be deduplicated
QSM: The files in the file system gain new identity (inode numbers etc.) in the destination system. Therefore, file handles cannot be migrated to the destination system
VSM:The files in the file system have the same identity on both source and destination system
QSM: LUN clones can be created on the destination volume, but not in the destination qtree
VSM:LUN clones cannot be created on the destination volume because the volume is read-only. However, LUN clones can be created on a FlexClone volume because the FlexClone volume is writable
No comments:
Post a Comment