snapshot names reverting after snap restore

[rkaramchedu1]

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>

[adamfox · Accepted solution]

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]

Yes it does. Thank you.

[JCASON]

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]

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]

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]

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.