ONTAP Discussions

SNAPDRIVE SNAPSHOTS

syedkhan
6,294 Views

I have weird spanshot called  {9ec98bf7-fd19-4471-9b95-b15a52abbeb7} in the snapdrive and its in the consistent state if I compare it with the other snapshot they have the server name, date and time but the above name is diffrent.

 

1) Why the name is generated like this and why it takes so much space if compared with the other snapshots

 

2) can I delete it ? if yes what will be the impact ? 

 

Please see the attadched to understand completely

 

1 ACCEPTED SOLUTION

ADVUNIPU1
6,261 Views

These are snapshots definately initiated by SMEIn the backup process initiated by SME  there is the Microsoft Volume Shadow Copy Service (VSS) involved, which creates these snapshots that are named like {Shadow_Copy_GUID}. In the later process of the SME backup these snapshots are renamed by SME to sth like exchsnap_hostname_date_time.   Now when the communication between SnapDrive and ONTAP is disturbed or broken for whatever reason while deleting snapshots via SME, these snapshots are not renamed/deleted as intended. SME manages  though to delete the SnapInfo metadata. So there is no way for SME to clean this up properly.

 

These snapshots are orphaned and can be deleted with no impact whatsoever.

See Bug https://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=808158

 

Peter

View solution in original post

5 REPLIES 5

ADVUNIPU1
6,262 Views

These are snapshots definately initiated by SMEIn the backup process initiated by SME  there is the Microsoft Volume Shadow Copy Service (VSS) involved, which creates these snapshots that are named like {Shadow_Copy_GUID}. In the later process of the SME backup these snapshots are renamed by SME to sth like exchsnap_hostname_date_time.   Now when the communication between SnapDrive and ONTAP is disturbed or broken for whatever reason while deleting snapshots via SME, these snapshots are not renamed/deleted as intended. SME manages  though to delete the SnapInfo metadata. So there is no way for SME to clean this up properly.

 

These snapshots are orphaned and can be deleted with no impact whatsoever.

See Bug https://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=808158

 

Peter

syedkhan
6,252 Views

That was an exact answer to the point. 

 

I have seen the snapshots which are shown in the Snapdrives are reflected on the volume as well.

can I delete the snaphots manually to reclaim the space or shall I delete it from the snapdrive ? 

 

ADVUNIPU1
6,219 Views

You can delete them manually. Or via snapdrive. It doesn't matter much. Space reclamation should happen from like instantly to within minutes. Depends on how many younger and older snapshots are kept on that volume. ONTAP has to figure out which blocks are still kept within other snapshots and which blocks can be considered as free blocks.

Or did you mean to mention SnapDrive space reclamation implicitly?

In that case:  snapdrive space reclamation does not apply for snapshots, only for freed blocks in the active file system.

 

Peter

syedkhan
6,164 Views

No I meant specifically about the OLD snapshots.

 

I have a last question.

 

Sanpshots are incremental isnt it ? If yes then where is the base snapshot ?

 

 

ADVUNIPU1
6,136 Views

Nope. Snapshots are a copy of the inode table. The term "base snapshot" does not apply to local snapshots.

There are lots of features that are based on these snapshots. One of these features is snapmirror, which is replication (sync or async) from one ONTAP System to another. After initiating a snapmirror (after the initial transfer is finished, that is) only the changed blocks are transmitted from the source to the destination. You can call this incemental. In order to figure out, which blocks have changed since the last transfer, the base snapshot is used. The base snapshot is the last common snapshot  that resides on both source and destination. SnapMirror requires the common base snapshot to exist on both the source and destination volumes for updates.

 

Peter

Public