ONTAP Discussions

snapshot names reverting after snap restore

rkaramchedu1
5,103 Views

IHAC who is seeing this behavior and I've verified it in the 7.3.2 simulator

  1. create a snapshot
  2. rename the snapshot
  3. perform a snap restore of the volume using the snapshot
  4. volume is restored - however, the containing snapshot has the original name created in step #1, not the new name from step #2

Is this intentional/expected?

simtap> snap create sqlproddata snapshot1

simtap> snap list sqlproddata

Volume sqlproddata

working...

  %/used       %/total  date          name

----------  ----------  ------------  --------

  0% ( 0%)    0% ( 0%)  Feb 09 07:39  snapshot1  

simtap> snap rename sqlproddata snapshot1 snapshotnew

simtap> snap list sqlproddata                    

Volume sqlproddata

working...

  %/used       %/total  date          name

----------  ----------  ------------  --------

  0% ( 0%)    0% ( 0%)  Feb 09 07:39  snapshotnew

simtap> snap restore -s snapshotnew sqlproddata

WARNING! This will revert the volume to a previous snapshot.

All modifications to the volume after the snapshot will be

irrevocably lost.

Volume sqlproddata will be made restricted briefly before coming back online.

Are you sure you want to do this? y

You have selected volume sqlproddata, snapshot snapshotnew

Proceed with revert? y

Tue Feb  9 07:39:58 EST [wafl.snaprestore.revert:notice]: Reverting volume sqlproddata to a previous snapshot.

Volume sqlproddata: revert successful.

simtap> snap list sqlproddata              

Volume sqlproddata

working...

  %/used       %/total  date          name

----------  ----------  ------------  --------

  0% ( 0%)    0% ( 0%)  Feb 09 07:39  snapshot1     

simtap>

1 ACCEPTED SOLUTION

adamfox
5,103 Views

Yes, this is normal and expected.  A snapshot is a frozen copy of everything at the time of the snapshot including the names of the snapshots that existed at the time of the snapshot.

The name change on the snapshot is no different than changing the name of a file in the snapshot from a WAFL perspective.

Hope this helps

View solution in original post

6 REPLIES 6

adamfox
5,104 Views

Yes, this is normal and expected.  A snapshot is a frozen copy of everything at the time of the snapshot including the names of the snapshots that existed at the time of the snapshot.

The name change on the snapshot is no different than changing the name of a file in the snapshot from a WAFL perspective.

Hope this helps

rkaramchedu1
5,104 Views

Yes it does. Thank you.

JCASON
5,103 Views

I know this is an old post but we recently ran into this issue which was confusing.

I wanted to add that the snapshot does seem to restore the snapshot names (which is bizarre itself), but that is it.  My understanding is a snapshot does not actually reference anything in other snapshots.  It only knows about its own blocks, which reference the active file system at the time of snap creation.

The point I wanted to clarify is not with snapshot renaming, but with snapshot deleting.

I ran through this test scenario which you can repeat yourself:

  1. Create 3 snapshots, named snap1, snap2, snap3 (in that order).
  2. Rename snap2 to be chgsnap2.
  3. Delete snap1.
  4. Snap restore from chgsnap2

You will end up with 1 snapshot named snap2.  Snap1 doesn't re-appear, even though it existed when snap2 was created.

Just wanted to add clarification to your "a snapshot is a frozen copy of everything" statement.  It is a frozen copy of everything in the active file system, as well as (apparently) names of snapshots.

gavin_meadows
5,103 Views

Hi jcason,

I just came across this and tried to replicate in my lab:

>snap create vol1 snapa
>snap create vol1 snapb
>snap create vol1 snapc

At this point you have snapa, snapb, snapc


>snap rename vol1 snapb snapb-1

Now you have snapa, snapb-1, snapc


>snap restore -t vol -s snapb-1 /vol/vol1

snapshots after restore snapa & snapb - this is what I would have expected.  Not sure what happened to your snap1

JCASON
5,103 Views

Yes that is expected.  My snap1 was gone because I manually deleted it (my step #3).

If you repeat your steps, but before your snaprestore you do "snap delete vol1 snapa", you will find that it remains deleted after the snaprestore.  It is gone, even though it existed at the time you took snapb, because snapb is only a snapshot of the active filesystem.

gavin_meadows
5,104 Views

Yes thats true - its all about the root inode of the AFS.  Over-simplifying it somewhat here - A snapshot is just a copy of that one 4k file that references all the data on the volume. A snapshot always makes a copy of the AFS root inode and marks all the blocks it points to as read only.  So when you do a Snap Restore it recovers the data on those blocks that its copy of the root inode is pointing to - it doesnt know that another copy of the root inode has been deleted (eg when you deleted snap1).

Deleting a Volume Snapshot copy is irreversable.

Unless.... you do an aggregate Snap Restore but this would restore/revert all volumes on the aggregate

>aggr create aggr1 -B 64 5

>snap reserve -A aggr1 5

>vol create vol1 -s none aggr1 200m

>qtree security /vol/vol1 ntfs

>cifs shares -add vol1 /vol/vol1

create file snapfile1.txt on share vol1

>snap create vol1 snap1

create file snapfile2.txt on share vol1

>snap create vol1 snap2

>snap create -A aggr1 aggr1snap

delete files snapfile1 & snapfile2

>snap delete vol1 snap1

>snap delete vol1 snap2

So now the files have been deleted and so have the Snaphot copies that referenced those files

>snap restore -A -s aggr1snap aggr1

Everything restored.  Both deleted files and both deleted Snapshots are back.

Public