ONTAP Discussions

Snapvault transferring is frozen

stephnane
5,584 Views

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.

6 REPLIES 6

radek_kubka
5,584 Views

Hi,

Can you simply try snapvault abort command?

Regards,

Radek

stephnane
5,584 Views

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
5,584 Views

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
5,584 Views

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
5,584 Views

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

stephnane
5,584 Views

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

Tks a lot.

Public