SnapMirror then SnapVault\Snapmirror to Tape

[adrianlowe]

My current scenerio:

Primary Site FAS3160 with a Snapmirror license and a SnapVault_pri license.

Secondary Site FAS3160 with a Snapmirror license, a SnapVault_pri license and a Tape library.

The customer ideally wants a DR setup from PRI to DR site - which can be achieved using snapmirror. Although then it leaves the dilema of SnapMirror (snapmirror store) to tape. Which when looking through the online backup documentation doesn't appear to support that method. It would allow you to snapmirror to a snapmirror source to tape but NOT the destination to tape.

I also believe you cand snapvault from the primary site to seconardy site (although this would require a snapvault_sec license) and then you can Snapmirror (snapmirror store) the the snapvault destination to tape. This solution would elmiate the DR setup which is required.

I have some potential ideas which I wanted some help/guidance with:

Source to destination to tape.

1. SnapMirror from source to destination. Then NDMP from snapmirror destination to tape. (although using ndmp means they would loose the benefit of dedup of the snapmirro destination to tape)

2. SnapMirror from source to destination. Then is is possible to SnapVault the snapmirror destination locally (using just the snapvault_pri license) so it keeps the DR functionality and then provides the SnapVault rention/backup of snapshots on its own volume. Then use Snapmirror (snapmirror store) to backup the SnapVaulted volume (on the DR storage) to Tape.

It should be possible to use snapmirror store of the snapvault primary volume as if it was a snapvault destination volume - correct? Using this method they would need to create a restricted volume for the snapmirror destination volume and a second volume for snapvault volume to take snapshots of the snapmirrored volume. (consuming more netapp storage space but allowing the dedup data to be snapmirrored to tape (saving space on the Tape))

Any help or other suggestions would be greately appreciated.

Best Regards,

Adrian

[adrianlowe]

A third method which I believe would be a better method. is

3. Snapmirror and Snapvault the same source vol to two different volumes on the destination so it hits the DR and the backup windows and back up to tape solution.

Primary site - VolA

(SnapMirrored to Secondary Site VolA_Rep) &

(SnapVaulted to Secondary Site VolA_SV) Then the snapmirror the snapvaulted VolA_SV to Tape which I know is supported.

Questions around then:

1. Snapvault_pri and Snapvault_sec will need to be licensed

2. Can you SnapMirror and Snapvault from the SAME source vol (in this case VolA)?

3. This will obviously double up bandwidth requirement when transfering across the WAN link between Primary to Secondary Site.

4. I believe the snapmirror and snavault relationships are is limited to a certain number of concurrent connections.

Would anyone be able to confirm this solution and provide any additional details which I might of missed.

Best Regards,

Adrian

[jmerrill]

Adrian,

1. SnapMirror from source to destination. Then NDMP from snapmirror destination to tape. (although using ndmp means they would loose the benefit of dedup of the snapmirro destination to tape)

That is correct, you would lose the dedupe space savings to tape.

2. SnapMirror from source to destination. Then is is possible to SnapVault the snapmirror destination locally (using just the snapvault_pri license) so it keeps the DR functionality and then provides the SnapVault rention/backup of snapshots on its own volume. Then use Snapmirror (snapmirror store) to backup the SnapVaulted volume (on the DR storage) to Tape. 
It should be possible to use snapmirror store of the snapvault primary volume as if it was a snapvault destination volume - correct? Using this method they would need to create a restricted volume for the snapmirror destination volume and a second volume for snapvault volume to take snapshots of the snapmirrored volume. (consuming more netapp storage space but allowing the dedup data to be snapmirrored to tape (saving space on the Tape))

I'm not sure I 100% follow the flow here.  In order to use SnapVault, you need both Primary and Secondary SnapVault licenses.

3. Snapmirror and Snapvault the same source vol to two different volumes on the destination so it hits the DR and the backup windows and back up to tape solution.
Primary site - VolA
(SnapMirrored to Secondary Site VolA_Rep) &
(SnapVaulted to Secondary Site VolA_SV) Then the snapmirror the snapvaulted VolA_SV to Tape which I know is supported.

Yes, this would also work, but you could also run SM between VolA and VolA_Rep, then use SnapVault to replicate from VolA_Rep to VolA_SV - this would allow only 1 transfer over the WAN and then SV within the same destination system (from the VSM destination - which would also be your SnapVault Source - to a SnapVault destination.

1. Snapvault_pri and Snapvault_sec will need to be licensed

Yes, both licenses would be required regardless of the solution chosen if you want to use SnapVault.

2. Can you SnapMirror and Snapvault from the SAME source vol (in this case VolA)?

Yes, this can be done, but I think a modified version of the 3rd option would work better - just note there are some restrictions with running a VSM-SV cascade - if you aren't at 7.3.2, then SV will always use a VSM created snapshot - which isn't an issue if this isn't an application environment.

3. This will obviously double up bandwidth requirement when transfering across the WAN link between Primary to Secondary Site.

Correct, which is why the modified 3rd option I mentioned may be a better fit.  In addition, this will allow VSM to replicate the data in a deduped state.

4. I believe the snapmirror and snavault relationships are is limited to a certain number of concurrent connections.

Yes, there are limitations on maximum concurrent replications.  These numbers are a fucntion of the version of ONTAP, Nearstore license, and Controller.

Also, I see that tape is still discussed, is this a requirement, or just something a customer would like to have?

Thanks!

Jeremy

[adrianlowe]

Hello Jeremy,

Thank you for the reply, that was an excellent answer. Regarding the tape backup, they have it as a requirement so from that and with the suggestion above I see there are multiple methods to then backup to tape.

1. NDMP the volumes at the destination (SnapVault volumes in this case) to the Tape. loose dedup like we stated above

2. Snapmirror store the snapvaulted destination volume to tape - this is the method I beleive is suitable.

3. or use a third party integration tool i.e. backup exec to manage ndmp and the schedules and so on. Also i believe this will also be the same as the first option i.e. the dedup wont be carried over.

Is there a 4th option? and which option would you recommend?

Best regards,

Adrian

[jmerrill]

Adrian,

1. NDMP the volumes at the destination (SnapVault volumes in this case) to the Tape. loose dedup like we stated above

That is correct - also note that a 3rd party application would need to do this - looks like BackupExec in your case.  Also, if this is the case, I would recommend the customer doesn't go to tape as frequently since most of their recover points will be on disk.

2. Snapmirror store the snapvaulted destination volume to tape - this is the method I beleive is suitable.

Yes, this should work - same as above - this probably wouldn't be the done as often.

 3. or use a third party integration tool i.e. backup exec to manage ndmp and the schedules and so on. Also i believe this will also be the same as the first option i.e. the dedup wont be carried over.

Correct, it would really be an extension of the 1st option.

Is there a 4th option? and which option would you recommend?

The only other thing I could think of would be discussing with the customer to think about reducing/eliminating tape in their environment.

Thanks!

Jeremy

[adrianlowe]

Hello Jeremy,

Just one other question regarding the setup above.

If "volA" on primary site consists of qtrees i.e. qtree1 and qtree2.

Then we perform a VSM (volume level snapmirror) to the Destination filer volume "volA_dr" (but not at Qtree level) so it sends the data in a dedup manor across the WAN link.

Then we do the suggested method above. When we then try to do SnapVault of the backup of the mirrored volume (volA_dr) we need to specify a qtree as opposed to the overall volume target. Will this be fine providing you know the Qtree names within the snapmirror copy of the data?

The reason I ask - is because i'm putting this in to synergy and it's straight forward doing the:

snapmirror from primary volA source to secondary snapmirror volum volA_dr

and then

snavault from primary volA source to secondary snapvault volume volA_backup.

But when you have to put it in synergy, the snapvault can't specify a qtree on the snapmirror volA_dr because its just a volume at the moment until the data is copied. I believe this might just be a synergy thing and when you carry out the implementation it should work.

I guess my question is; if you do VSM from Pri to DR, can you still then do the snapvault (qtree level) of the snapmirrored DR vol to a snapvault volume volA_backup (as we suggested above?) or does the snapmirror replication need to be a QSM replication? or will the original suggestion be fine.

Apologies if i've confused the situation.

Best Regards,

Adrian Lowe

[jmerrill]

Adrian,

Sorry for the delay in the reply.

If "volA" on primary site consists of qtrees i.e. qtree1 and qtree2.
Then we perform a VSM (volume level snapmirror) to the Destination filer volume "volA_dr" (but not at Qtree level) so it sends the data in a dedup manor across the WAN link.
Then we do the suggested method above. When we then try to do SnapVault of the backup of the mirrored volume (volA_dr) we need to specify a qtree as opposed to the overall volume target. Will this be fine providing you know the Qtree names within the snapmirror copy of the data?
The reason I ask - is because i'm putting this in to synergy and it's straight forward doing the:
snapmirror from primary volA source to secondary snapmirror volum volA_dr
and then
snavault from primary volA source to secondary snapvault volume volA_backup.
But when you have to put it in synergy, the snapvault can't specify a qtree on the snapmirror volA_dr because its just a volume at the moment until the data is copied. I believe this might just be a synergy thing and when you carry out the implementation it should work.
I guess my question is; if you do VSM from Pri to DR, can you still then do the snapvault (qtree level) of the snapmirrored DR vol to a snapvault volume volA_backup (as we suggested above?) or does the snapmirror replication need to be a QSM replication? or will the original suggestion be fine.
Apologies if i've confused the situation.

Nope, I think you have it...the replication MUST be VSM and then SV because you can't cascade SV or QSM, meaning you can't have QSM then SV (or any combination of the 2).

If the data on the VSM Destination isn't in a qtree, then you would need to use a "-" in place of the source qtree in the snapvault start command.  You would still need to specify a destnation qtree though on the SV destination volume.

Please also check out TR-3487 (attached) for more information on the VSM to SV cascade and some things you need to be aware of.

Hope this helps!

Jeremy