Toasters --
Having abandoned synch SnapMirror due to compatibility issues, we are looking to asynch snaps for BCP/DR. Unfortunately we still need to cut the SnapMirror destination (7.2.4) to tape via NDMP. It looks like an outstanding bug http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=36554 and corresponding KB article http://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb44293 indicate that the schedules of SnapMirror and NDMP moves should never compete with one another due to tripping on one another's snaps.
So we either need to
1.) break the mirror in order to blow out backups, or 2.) setup a SnapMirror schedule which leaves a window for scheduled backups.
$mgmt would much prefer the first option in order to maximize replication, and since no one is able to confirm test numbers for backup time duration. So ... any production tips on hailing the SnapMirror destination to break when its time to get our NDMP on? And resync'ing upon NDMP completion? Or am I really off-base with the above? :)
Insight appreciated. Thanks.
Those are some ways to go but may I add some options to your list
3) Base your NDMP backups on an existing snapshot that exists in the volume. 4) Spin off a Flex Clone of your destination volume, dump based on that, then blow away the clone when you're done.
-- Adam Fox adamfox@netapp.com
-----Original Message----- From: Nick Silkey [mailto:silkey@ece.utexas.edu] Sent: Monday, October 20, 2008 12:06 PM To: toasters@mathworks.com Subject: SnapMirror and NDMP ; competing snap schedules?
Toasters --
Having abandoned synch SnapMirror due to compatibility issues, we are looking to asynch snaps for BCP/DR. Unfortunately we still need to cut the SnapMirror destination (7.2.4) to tape via NDMP. It looks like an outstanding bug http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=36554 and corresponding KB article http://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb44293 indicate that the schedules of SnapMirror and NDMP moves should never compete with one another due to tripping on one another's snaps.
So we either need to
1.) break the mirror in order to blow out backups, or 2.) setup a SnapMirror schedule which leaves a window for scheduled backups.
$mgmt would much prefer the first option in order to maximize replication, and since no one is able to confirm test numbers for backup time duration. So ... any production tips on hailing the SnapMirror destination to break when its time to get our NDMP on? And resync'ing upon NDMP completion? Or am I really off-base with the above? :)
Insight appreciated. Thanks.
Did you experience problem or are you suspecting that you may experience it. If you take a closer look at the bug report that you should see that it refers to Ontap 6.1 and has been fixed since Ontap 6.4. Therefor this historic problem does not apply to 7.2.4.
Ernie
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Nick Silkey Sent: Monday, October 20, 2008 6:06 PM To: toasters@mathworks.com Subject: SnapMirror and NDMP ; competing snap schedules?
Toasters --
Having abandoned synch SnapMirror due to compatibility issues, we are looking to asynch snaps for BCP/DR. Unfortunately we still need to cut the SnapMirror destination (7.2.4) to tape via NDMP. It looks like an outstanding bug http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=36554 and corresponding KB article http://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb44293 indicate that the schedules of SnapMirror and NDMP moves should never compete with one another due to tripping on one another's snaps.
So we either need to
1.) break the mirror in order to blow out backups, or 2.) setup a SnapMirror schedule which leaves a window for scheduled backups.
$mgmt would much prefer the first option in order to maximize replication, and since no one is able to confirm test numbers for backup time duration. So ... any production tips on hailing the SnapMirror destination to break when its time to get our NDMP on? And resync'ing upon NDMP completion? Or am I really off-base with the above? :)
Insight appreciated. Thanks.
-- Nick
-
Bokkelkamp, Ernst -
Fox, Adam -
Nick Silkey