Hi all,
We've got some filers, SRC (6.5.1R1P12) and DEST (6.5.2R1) which are doing snapvaults across a WAN. Someone deleted an active (I think) snapvault snapshot on the source filer to make space. At least they did delete a snapshot on the SRC filer which was our base snapshot for snapvault to the filer DEST.
Currently, I'm seeing the following on the secondary:
# rsh dest snapvault status -l /vol/vol2/src_vol3_proj Snapvault secondary is ON.
Source: src:/vol/vol3/proj Destination: dest:/vol/vol2/src_vol3_proj Status: Quiescing Progress: - State: Snapvaulted Lag: 11:59:33 Mirror Timestamp: Fri Feb 4 01:00:01 PST 2005 Base Snapshot: dest(0050404441)_vol2-base.0 Current Transfer Type: Update Current Transfer Error: base snapshot for transfer no longer exists on the source Contents: Replica Last Transfer Type: Update Last Transfer Size: 1137360 KB Last Transfer Duration: 00:43:47 Last Transfer From: src:/vol/vol3/proj
It's been hung like this for a while now, say 8 hours. The src filer now has a couple of hourly snapvault snapshots online:
# rsh src snap list vol3 Volume vol3 working...
%/used %/total date name ---------- ---------- ------------ -------- 0% ( 0%) 0% ( 0%) Feb 04 16:00 sv_hourly.0 0% ( 0%) 0% ( 0%) Feb 04 15:00 sv_hourly.1
Do I just need to wait for the secondary (an R200) to finish quiescing it's side of things before I can restart the snapvault process? Or do I need to re-do the entire base snapvault all over again?
Thanks, John John Stoffel - Senior Staff Systems Administrator - System LSI Group Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec john.stoffel@taec.toshiba.com - 508-486-1087
you can't easily delete the source snapshot, because they have the "snapmirror" flag added. The only way someone could have deleted it is by stopping the snapvault relationship. So this could be some other issue, not necessarily a deleted snapshot. what does the snap list command show on the pri and secondary? My example.. Source: snap list vol1 Volume vol1 working...
%/used %/total date name ---------- ---------- ------------ -------- 0% ( 0%) 0% ( 0%) Feb 04 12:00 sv_hourly.0 (snapmirror)
Destination: snap list vol1 |more Volume vol1 working...
%/used %/total date name ---------- ---------- ------------ -------- 0% ( 0%) 0% ( 0%) Feb 04 12:16 sv_hourly.0 0% ( 0%) 0% ( 0%) Feb 04 12:14 xxxxx(0050394636)_vol1-base.0 (busy,snapmirror)
Hope this helps in you troubleshooting. -G
On Fri, 4 Feb 2005 16:00:58 -0500, John Stoffel john.stoffel@taec.toshiba.com wrote:
Hi all,
We've got some filers, SRC (6.5.1R1P12) and DEST (6.5.2R1) which are doing snapvaults across a WAN. Someone deleted an active (I think) snapvault snapshot on the source filer to make space. At least they did delete a snapshot on the SRC filer which was our base snapshot for snapvault to the filer DEST.
Currently, I'm seeing the following on the secondary:
# rsh dest snapvault status -l /vol/vol2/src_vol3_proj Snapvault secondary is ON.
Source: src:/vol/vol3/proj Destination: dest:/vol/vol2/src_vol3_proj Status: Quiescing Progress: - State: Snapvaulted Lag: 11:59:33 Mirror Timestamp: Fri Feb 4 01:00:01 PST 2005 Base Snapshot: dest(0050404441)_vol2-base.0 Current Transfer Type: Update Current Transfer Error: base snapshot for transfer no longer exists on the source Contents: Replica Last Transfer Type: Update Last Transfer Size: 1137360 KB Last Transfer Duration: 00:43:47 Last Transfer From: src:/vol/vol3/proj
It's been hung like this for a while now, say 8 hours. The src filer now has a couple of hourly snapvault snapshots online:
# rsh src snap list vol3 Volume vol3 working...
%/used %/total date name
0% ( 0%) 0% ( 0%) Feb 04 16:00 sv_hourly.0 0% ( 0%) 0% ( 0%) Feb 04 15:00 sv_hourly.1Do I just need to wait for the secondary (an R200) to finish quiescing it's side of things before I can restart the snapvault process? Or do I need to re-do the entire base snapvault all over again?
Thanks, John John Stoffel - Senior Staff Systems Administrator - System LSI Group Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec john.stoffel@taec.toshiba.com - 508-486-1087
"Sto" == Sto Rage© netbacker@gmail.com writes:
Sto> you can't easily delete the source snapshot, because they have Sto> the "snapmirror" flag added. The only way someone could have Sto> deleted it is by stopping the snapvault relationship. So this Sto> could be some other issue, not necessarily a deleted Sto> snapshot. what does the snap list command show on the pri and Sto> secondary?
Yeah, they did stop the snapvault relationship (or did a force) to delete the source snapshot. It did end up going idle on the destination filer, but I couldn't modify or start it back up. So now I've bitten the bullet and I'm doing
snapvault stop dest:/vol/vol2/src_vol3_proj
to clean up stuff, and then I'll do a 'start' once the stop finishes. Oh well... this just gives me more ammo to beat people up on keeping enough snap reserve space around no matter what.
John
-
John Stoffel -
Sto Rage©