We using SnapMirror for three filers in a cascade. filerA is the master so we normally cascade SnapMirror as filerA->filerB->filerC.
In the case of a DR event, we'll repoint things so we end up with filerB->filerA->filerC or filerC->filerA->filerB or some combination like that. After the DR event is over, we put restructure the cascade so that it goes A->B->C as noted above. As part of this restructuring, we will do a 'snapmirror release' for any relationships that no longer exist after things are repointed. Generally this cleans up any snapshots that we don't need and things are happy.
Recently, I noticed that we have a couple of old and somewhat large snapshots that never expire. These have been around for a couple of months and are hogging 5-10% of a volume that's already pretty full. I'd like to delete them but I don't see any Broken-Off relationships when I run 'snapmirror status <volume>'. I'm just not comfortable winging it with release until I get a better grasp on how SnapMirror got into this state.
Looking at 'snapmirror destinations -s <volume>' I have a pretty good idea of how things were pointed in our cascade during DR events that generated these snapshots in the first place, but I remain unclear about how to (or even if I can!) do a snapmirror release in this case.
Please advise!
When you resync or otherwise change the directions of the snapmirrors, a "snapmirror release" will remove the snapmirror tag from the snapshots, but will not remove the snapshots. You should also remove any snapshots on the new source that has a system-id of the new source. I do this everytime a direction changes, both when going into DR mode and when coming out.
George
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Nathan Patwardhan Sent: Monday, October 20, 2008 3:22 PM To: Toasters Subject: Question about SnapMirror, cascade, and deleting old snapshots.
We using SnapMirror for three filers in a cascade. filerA is the master so we normally cascade SnapMirror as filerA->filerB->filerC.
In the case of a DR event, we'll repoint things so we end up with filerB->filerA->filerC or filerC->filerA->filerB or some combination like that. After the DR event is over, we put restructure the cascade so that it goes A->B->C as noted above. As part of this restructuring, we will do a 'snapmirror release' for any relationships that no longer exist after things are repointed. Generally this cleans up any snapshots that we don't need and things are happy.
Recently, I noticed that we have a couple of old and somewhat large snapshots that never expire. These have been around for a couple of months and are hogging 5-10% of a volume that's already pretty full. I'd like to delete them but I don't see any Broken-Off relationships when I run 'snapmirror status <volume>'. I'm just not comfortable winging it with release until I get a better grasp on how SnapMirror got into this state.
Looking at 'snapmirror destinations -s <volume>' I have a pretty good idea of how things were pointed in our cascade during DR events that generated these snapshots in the first place, but I remain unclear about how to (or even if I can!) do a snapmirror release in this case.
Please advise!
-- Nathan Patwardhan "Of course, the US has many elements of socialism already since capitalists, like cats, tend to get themselves stuck up a tree every so often." -- Joe Johnston
On Tue, Oct 21, 2008 at 4:30 PM, George T Chen gtchen@yahoo-inc.com wrote:
When you resync or otherwise change the directions of the snapmirrors, a "snapmirror release" will remove the snapmirror tag from the snapshots, but will not remove the snapshots. You should also remove any snapshots on the new source that has a system-id of the new source. I do this everytime a direction changes, both when going into DR mode and when coming out.
I'm with you, but that's precisely why I'm unsure of why these snapshots still have a (snapmirror) tag. The system must be thinking that they're still used somehow.
Here's what I see now:
filerA> snap list perforce Volume perforce working...
%/used %/total date name ---------- ---------- ------------ -------- 0% ( 0%) 0% ( 0%) Oct 21 17:31 filerB(0101195068)_dr_perforce.5536 (snapmirror) 0% ( 0%) 0% ( 0%) Oct 21 17:11 filerB(0101195068)_dr_perforce.5534 (snapmirror) 0% ( 0%) 0% ( 0%) Oct 21 16:01 hourly.0 0% ( 0%) 0% ( 0%) Oct 21 12:00 hourly.1 0% ( 0%) 0% ( 0%) Oct 21 08:00 hourly.2 0% ( 0%) 0% ( 0%) Oct 21 00:01 nightly.0 0% ( 0%) 0% ( 0%) Oct 20 20:01 hourly.3 0% ( 0%) 0% ( 0%) Oct 20 16:00 hourly.4 0% ( 0%) 0% ( 0%) Oct 20 12:00 hourly.5 0% ( 0%) 0% ( 0%) Oct 20 00:01 nightly.1 1% ( 0%) 0% ( 0%) Oct 05 08:33 filerA(0101195225)_perforce.1 1% ( 0%) 0% ( 0%) Oct 05 06:22 filerB(0101195068)_dr_perforce.3573 (snapmirror) 1% ( 0%) 0% ( 0%) Oct 04 11:59 snapshot_for_backup.18595 5% ( 4%) 4% ( 3%) Aug 20 08:05 filerA(0101195225)_perforce.7 (snapmirror)
filerA> snapmirror status perforce Snapmirror is on. Source Destination State Lag Status filerA:perforce filerB:dr_perforce Source 00:16:05 Transferring
filerA> snapmirror destinations -s Path Snapshot Destination perforce filerA(0101195225)_perforce.7 filerB:dr_perforce->dr-perforce-2:dr2_perforce->filerA:perforce->filerB:dr_perforce->filerA:perforce perforce filerB(0101195068)_dr_perforce.3573 filerB:dr_perforce->dr-perforce-2:dr2_perforce->filerA:perforce->filerB:dr_perforce perforce filerB(0101195068)_dr_perforce.5534 filerB:dr_perforce->dr-perforce-2:dr2_perforce perforce filerB(0101195068)_dr_perforce.5536 filerB:dr_perforce
Given the above I'm trying to figure out why on earth filerA(0101195225)_perforce.7 still has a (snapmirror) tag. Do you have any ideas?
I know you say that you did the snapmirror release, so maybe there's a bug somewhere, but the presence of the snapmirror tag on snapshot "filerA(0101195225)_preforce.7" would indicate that the release never completed. That snapshot would have been created from when filerA was a snapmirror destination. Regardless, I believe you can safely remove the Aug 20 snapshot.
I do not believe the presence of the snapmirror tag means that "snapmirror status" will automatically include it. If you modify the /etc/snapmirror.conf file to include the old filerB-filerA entry, you should see the entry with a lag of months.
But then again, I don't have that much to lose by offering advice on a mailing list :-)
George
-----Original Message----- From: Nathan Patwardhan [mailto:noopy.org@gmail.com] Sent: Tuesday, October 21, 2008 2:48 PM To: George T Chen Cc: Toasters Subject: Re: Question about SnapMirror, cascade, and deleting old snapshots.
On Tue, Oct 21, 2008 at 4:30 PM, George T Chen gtchen@yahoo-inc.com wrote:
When you resync or otherwise change the directions of the snapmirrors, a
"snapmirror release" will remove the snapmirror tag from the snapshots, but will not remove the snapshots. You should also remove any snapshots on the new source that has a system-id of the new source. I do this everytime a direction changes, both when going into DR mode and when coming out.
I'm with you, but that's precisely why I'm unsure of why these snapshots still have a (snapmirror) tag. The system must be thinking that they're still used somehow.
Here's what I see now:
filerA> snap list perforce Volume perforce working...
%/used %/total date name
0% ( 0%) 0% ( 0%) Oct 21 17:31 filerB(0101195068)_dr_perforce.5536 (snapmirror) 0% ( 0%) 0% ( 0%) Oct 21 17:11 filerB(0101195068)_dr_perforce.5534 (snapmirror) 0% ( 0%) 0% ( 0%) Oct 21 16:01 hourly.0 0% ( 0%) 0% ( 0%) Oct 21 12:00 hourly.1 0% ( 0%) 0% ( 0%) Oct 21 08:00 hourly.2 0% ( 0%) 0% ( 0%) Oct 21 00:01 nightly.0 0% ( 0%) 0% ( 0%) Oct 20 20:01 hourly.3 0% ( 0%) 0% ( 0%) Oct 20 16:00 hourly.4 0% ( 0%) 0% ( 0%) Oct 20 12:00 hourly.5 0% ( 0%) 0% ( 0%) Oct 20 00:01 nightly.1 1% ( 0%) 0% ( 0%) Oct 05 08:33 filerA(0101195225)_perforce.1 1% ( 0%) 0% ( 0%) Oct 05 06:22 filerB(0101195068)_dr_perforce.3573 (snapmirror) 1% ( 0%) 0% ( 0%) Oct 04 11:59 snapshot_for_backup.18595 5% ( 4%) 4% ( 3%) Aug 20 08:05 filerA(0101195225)_perforce.7 (snapmirror)
filerA> snapmirror status perforce Snapmirror is on. Source Destination State Lag Status filerA:perforce filerB:dr_perforce Source 00:16:05 Transferring
filerA> snapmirror destinations -s Path Snapshot Destination perforce filerA(0101195225)_perforce.7 filerB:dr_perforce->dr-perforce-2:dr2_perforce->filerA:perforce-
filerB:dr_perforce->filerA:perforce
perforce filerB(0101195068)_dr_perforce.3573 filerB:dr_perforce->dr-perforce-2:dr2_perforce->filerA:perforce-
filerB:dr_perforce
perforce filerB(0101195068)_dr_perforce.5534 filerB:dr_perforce->dr-perforce-2:dr2_perforce perforce filerB(0101195068)_dr_perforce.5536 filerB:dr_perforce
Given the above I'm trying to figure out why on earth filerA(0101195225)_perforce.7 still has a (snapmirror) tag. Do you have any ideas?
-- Nathan Patwardhan "Of course, the US has many elements of socialism already since capitalists, like cats, tend to get themselves stuck up a tree every so often." -- Joe Johnston
-
George T Chen -
Nathan Patwardhan