Snapvault transferring is frozen

stephnane · ‎2012-06-07

Hi.

Data Ontap 7.3.3 on both boxes.

One of our snapvault replication is frozen (the progress size doesn't change) but I dont know how to unfreeze this situation.

Here is the "snapvault status -l" :

myfiler> snapvault status -l srcfiler:/vol/vol3/Metiers

Snapvault is ON.

Source: srcfiler:/vol/vol3/Metiers

Destination: myfiler:/vol/sv_803_vol3/Metiers

Status: Transferring

Progress: 36449116 KB

State: Snapvaulted

Lag: 1358:50:23

Mirror Timestamp: Wed Apr 11 20:00:55 CEST 2012

Base Snapshot: myfiler(0135067612)_sv_803_vol3-base.0

Current Transfer Type: Update

Current Transfer Error: -

Contents: Transitioning

Last Transfer Type: Update

Last Transfer Size: 1576360 KB

Last Transfer Duration: 01:35:05

Last Transfer From: srcfiler:/vol/vol3/Metiers

The snapshot from Wed Apr 11 20:00:55 CEST 2012 is still here on the srcfiler :

srcfiler> snap list
Volume vol3
working...
  %/used       %/total  date          name
----------  ----------  ------------  --------
  0% ( 0%)    0% ( 0%)  Jun 07 00:01  hourly.0
  0% ( 0%)    0% ( 0%)  Jun 06 20:01  journalier.0   (acs)
  0% ( 0%)    0% ( 0%)  Jun 06 12:00  hourly.1
  0% ( 0%)    0% ( 0%)  Jun 06 00:01  hourly.2
  0% ( 0%)    0% ( 0%)  Jun 05 20:01  journalier.1
  0% ( 0%)    0% ( 0%)  Jun 05 12:00  hourly.3
  0% ( 0%)    0% ( 0%)  Jun 05 00:01  hourly.4
  1% ( 1%)    1% ( 1%)  Jun 04 12:00  hourly.5
  1% ( 0%)    1% ( 0%)  Jun 04 00:01  hourly.6
  1% ( 0%)    1% ( 0%)  Jun 03 12:00  hourly.7
  1% ( 0%)    1% ( 0%)  Jun 03 00:01  hourly.8
  1% ( 0%)    1% ( 0%)  Jun 02 12:00  hourly.9
  1% ( 0%)    1% ( 0%)  Jun 02 00:01  hourly.10
  2% ( 1%)    2% ( 1%)  Jun 01 12:00  hourly.11
  2% ( 0%)    2% ( 0%)  Jun 01 00:01  hourly.12
  2% ( 0%)    2% ( 0%)  May 31 12:01  hourly.13
  3% ( 2%)    3% ( 1%)  Apr 11 20:00  journalier.2   (snapvault)

And on the "target" filer :

myfiler> snap list sv_803_vol3
Volume sv_803_vol3
working...
  %/used       %/total  date          name
----------  ----------  ------------  --------
  0% ( 0%)    0% ( 0%)  Apr 11 21:58  journalier.0
  0% ( 0%)    0% ( 0%)  Apr 11 21:40  myfiler(0135067612)_sv_803_vol3-base.0 (busy,snapvault)
  0% ( 0%)    0% ( 0%)  Apr 10 22:57  journalier.1
  0% ( 0%)    0% ( 0%)  Apr 09 20:37  journalier.2
  0% ( 0%)    0% ( 0%)  Apr 08 20:34  journalier.3
  0% ( 0%)    0% ( 0%)  Apr 08 13:56  journalier.4
  0% ( 0%)    0% ( 0%)  Apr 07 14:27  journalier.5
  1% ( 0%)    1% ( 0%)  Apr 05 22:04  journalier.6
  1% ( 0%)    1% ( 0%)  Apr 04 21:44  journalier.7
  1% ( 0%)    1% ( 0%)  Apr 03 23:12  journalier.8
  1% ( 0%)    1% ( 0%)  Apr 03 01:25  journalier.9
  1% ( 0%)    1% ( 0%)  Apr 01 20:28  journalier.10
  1% ( 0%)    1% ( 0%)  Mar 31 21:50  journalier.11
  1% ( 0%)    1% ( 0%)  Mar 31 03:23  journalier.12
  2% ( 1%)    2% ( 1%)  Mar 29 22:00  journalier.13

Tks to help me.

radek_kubka · ‎2012-06-07

Hi,

Can you simply try snapvault abort command?

Regards,

Radek

stephnane · ‎2012-06-07

I can try, but my volume is about 880 GB, and I don't want to snapvault the entire volume through a WAN connection with low bandwidth. I have to be sure that the snapshot (which is old) will be resynchronized.

I'm not sure of what the snapvault abort do, I dont want to lose snapshots of April 11th.

Tks

radek_kubka · ‎2012-06-07

Does this help?

abort [-f] [ -h ] [dst_filer:]dst_path

abort -s volname snapname

Available on the primary and secondary. Cancels transfers to all dst_paths specified or, with the -s option, cancels the creation of a snapshot. The destination dst_path is on the secondary for normal updates, but is on the primary for restores. When cancelling a snapshot creation, the command also cancels all update transfers initiated as part of creating the snapshot.

Any transfer with a restart checkpoint (you can view this via the snapvault status command) may be restartable; to clear out the restart checkpoint and force any subsequent transfer to start from the beginning and possibly a different snapshot on the primary, you can use abort -h on the dst_path. The -h option specifies that this is a hard abort; the restart checkpoint will be cleared out in addition to the transfer being stopped.

The abort command can be invoked from either the primary or the secondary filer. However, the -h option is only effective on the destination filer. The option will be ignored if specified on the source filer.

The -f option forces the abort command to proceed without first asking for confirmation from the user.

stephnane · ‎2012-06-07

Are you sure that after this abort, it will restart from the snapshot of April 11th ?

Do the "snapvault update" command works to restart the transfer ?

radek_kubka · ‎2012-06-07

If you don't use -s option, then yes - it should restart the transfer from the last checkpoint.

stephnane · ‎2012-06-07

I made a snapshot abort, then snapshot update, it seems to work, the transfer has restarted from the same Base snapshot.

Tks a lot.