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