Snapvault volume larger than the aggregate - Snapvault stop

[BrendonHiggins]

A couple of our snapvaults have become larger than the 14Tb size of the aggregate.  We have had to break the snapvault and then re-seed to a new volume and continue snapvaulting to there.  The problem is the data is still required in the old volume, so it can not be removed from the system and the snapmirror status shows:

SAN01:/vol/f02db/-  SAN06:/vol/02db/exf02db        Snapvaulted    1119:28:27  Idle      <--   Closed

SAN01:/vol/f02db/-  SAN06:/vol/f02db_1/exf02db_1    Snapvaulted    15:14:04   Idle       <--  New  volume

The idle time is continuing to increase, causing issues with my snapvault lag time alerts and looks messy.

I think I need to use the snapvault close command to remove the 'closed' snapvault but the man pages states it also deletes the qtree.  Does this mean that the newest data in the closed snapvault is removed but all the snaps and data contained within them will still be available for future restores if required?

Thanks for any help, including alternative solutions.

Bren

[radek_kubka]

Hi Bren,

Have you seen this post from Adai?

http://communities.netapp.com/message/39968#39968

That's the bit which may be interesting for you:

The reaper process will cleanup the relationship within 2 to 3 hours.So  the new updates dont go to the old volume, but those backup version  registered with the dataset are available for restore.

Regards,

Radek

[lhoffman1]

Hi,

SAN01:/vol/f02db/-  SAN06:/vol/02db/exf02db        Snapvaulted    1119:28:27  Idle      <--   Closed

SAN01:/vol/f02db/-  SAN06:/vol/f02db_1/exf02db_1    Snapvaulted    15:14:04   Idle       <--  New  volume

the answer is just easy...   I understand, you wanted keep the data in the old snapvault volume 02db ... isn't ?

the new relationship to f02db_1  works fine and is actual.

You could use the old data as you want .   the way what you could do to reduce the space on the old volume

is to delete successive oldest snapshots  (snap list 02db), if you don't want the oldest data anymore...

But If you keep the complete old data, so you don't need delete any snaps...

Your idle time will increase every minute...

btw.  what do you mean with  "snapvault close"  ?   I don't know this command option !

Do you mean "stop" ?   Then be sure, all the data will be removed from the data area  (but are available in snapshots yet)

regards

Lutz Hoffmann

[BrendonHiggins]

32 to 64 bit aggr lets not go there!  Not possible with production data until next DoT unless you are feeling lucky.  Had a good look into that at the start of the year.  Thanks for the idea however.

Sorry noticed a typo in my 1st post:

"

The problem is the data is still required in the old volume, so it  can not be removed from the system and the snapmirror (should be snapvault) status shows:

SAN01:/vol/f02db/-  SAN06:/vol/02db/exf02db        Snapvaulted    1119:28:27  Idle      <--   Closed

SAN01:/vol/f02db/-  SAN06:/vol/f02db_1/exf02db_1    Snapvaulted    15:14:04   Idle       <--  New  volume"

Again having a bad day.  Snapvault close should be:

snapvault stop

stop [ -f ] secondary_qtree

Available on the secondary only. Unconfigures the qtree so there will be no more updates of the qtree and then deletes the qtree from the active file ...

Does this command just remove the 'current' baseline snapshot and qtree or all the data in the volume?

As another possible idea could I convert the snapvault into a flexvol?

priv set diag
filer*> snapvault convert /vol/flexvol/qtree

Thanks

Bren

[BrendonHiggins]

Page 16 - http://media.netapp.com/documents/tr-3466.pdf

DELETING RELATIONSHIPS
OSSV relationships can be deleted from the NetApp secondary system using the snapvault stop command. Issuing this command permanently destroys the relationship and the qtree to which the data was backed up. It does not, however, remove the Snapshot copies that contain the historical backup data unless the volume is manually destroyed as well.

For example, to delete a relationship run the following command on the NetApp secondary:

snapvault stop /vol/backups/ossv1

This removes this relationship and destroys the qtree, “ossv1.” The following warning is displayed after running the command, requiring confirmation.

Stopping /vol/backups/ossv1 is permanent.
The secondary qtree will be deleted.
Further incremental updates will be impossible.
Data already stored in snapshots will not be deleted.
This may take a long time to complete.
Are you sure you want to do this? Y