Skip to main content
Solved

Some Netapp Snapshots not in "List Snapshots"


Forum|alt.badge.img+3

I have a Commvault installation with Netapp Storage Arrays.

 

In our Netapp snapshots, we have multiple snapshots on different NAS volumes that have SP_X_XXXX_XXX which leads me to believe it is a snapshot that was create from Commvault. All of the settings say that data retention is only 30 days and the snapshots are not listed when clicking “List Snapshots” in the storage array. The only ones listed go back to last month, but in the Netapp Interface I'm seeing snapshots from 2018 that are yet to be deleted. 

Are these created by Commvault and have been forgotten? Was there an issue to delete these and Commvault no longer sees them? I can manually delete from Netapp, but I prefer to let Commvault do its job if possible. Has anyone else seen this?

I work in an environment I can unfortunately not provide screenshots.

Best answer by dude

Hey All,

Wanted to add to the discussion since I do see same behavior in our environment for years. "What I believe" it happens is a glitch in communication between Commvault and the Storage Array which then causes the Snaps to actually never gets pruned on the storage side.

So every couple months we have to revisit and run a command on our NetApp like;

snapshot show -vserver * -volume * -snapshot SP_* -create-time <300d -fields create-time , size

So that will bring any snapshots that starts with SP_ and are older than 300days from any vserver and volume on that system.

With that you can cross check the specific subclient you are wondering. And much like Mike mentioned, if they do not exist in your Commvault envir, you should be able to remove them from your NetApp array as long as they are not the reference copy for the snapmirror.

So this is not uncommon and there have been other users in the past asking the same question.


 

View original
Did this answer your question?

7 replies

MichaelCapon
Vaulter
Forum|alt.badge.img+14

There’s a few things that could have occurred causing the issue here, It could be anything from a failed/timed-out snap deletion/request or the Snap/Subclient deleted from Commvault side.

If those Snaps from 2018 are not listed in Commvault, I’d suggest manually pruning them from the Array since the logs for those will definitely be overwritten.

If you have any more recent occurrences of this issue then it may be worth opening a support case to investigate further. - We can check CVD/CVMA logs on the MA for the Snap pruning requests. 

 

Best Regards,

Michael


R Anwar
Vaulter
Forum|alt.badge.img+10
  • Vaulter
  • 102 replies
  • August 24, 2021

Hi @AndrewArmstrong45 
Are we using OCUM or NetApp Open Replication? Are we replicating Primary snaps to another array?

Regards,

Rashid


dude
Byte
Forum|alt.badge.img+15
  • Byte
  • 287 replies
  • Answer
  • August 24, 2021

Hey All,

Wanted to add to the discussion since I do see same behavior in our environment for years. "What I believe" it happens is a glitch in communication between Commvault and the Storage Array which then causes the Snaps to actually never gets pruned on the storage side.

So every couple months we have to revisit and run a command on our NetApp like;

snapshot show -vserver * -volume * -snapshot SP_* -create-time <300d -fields create-time , size

So that will bring any snapshots that starts with SP_ and are older than 300days from any vserver and volume on that system.

With that you can cross check the specific subclient you are wondering. And much like Mike mentioned, if they do not exist in your Commvault envir, you should be able to remove them from your NetApp array as long as they are not the reference copy for the snapmirror.

So this is not uncommon and there have been other users in the past asking the same question.


 


Forum|alt.badge.img+3

This is exactly what I was looking for. This makes sense, although I’m not fully understanding why there would be a lapse in communication. Are you aware if any of these snapshots are incremental to other snapshots typically? The last thing I would want to do would be to delete these old snapshots (Over 200) just to find out we are unable to restore moving forward (even though we never actually restore from Netapp).

-Andrew


dude
Byte
Forum|alt.badge.img+15
  • Byte
  • 287 replies
  • August 24, 2021
AndrewArmstrong45 wrote:

This is exactly what I was looking for. This makes sense, although I’m not fully understanding why there would be a lapse in communication.

Like I said, I think it is all related to the API communication there. There are times and I have seen this a lot where Commvault simple can not delete the snapshot some reason. You may run a snapshot delete from your subclient, a job is kicked up as a snap delete operation and it shows as completed with errors which essentially means that it did not delete the snap. Now a lot of times, the task of deletion may also take some time a good 10-20 mins until it actually completes but it then deletes the snaps from the source NetApp Array.

 

Like I said, in many cases when you are taking snaps on a regular basis, you probably are also on a daily most likely on a weekly basis copying the latest snapshot to local disk or cloud and so that would not matter anyways since you do have that week reflected on disk.

 

AndrewArmstrong45 wrote:

Are you aware if any of these snapshots are incremental to other snapshots typically?

NetApp snapshots are very efficient in a way that it only track changes on each snapshot that were made since the last snapshot.

I`d recommend the following: https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/Snapshots%3A_including_SnapShot_Issues_and_Solutions

 

AndrewArmstrong45 wrote:

The last thing I would want to do would be to delete these old snapshots (Over 200) just to find out we are unable to restore moving forward (even though we never actually restore from Netapp).

Again, 200 is a lot of snapshots and you probably do not want to keep them on SSD storage either. Depending on your setup, some of these snaps were already copied to Primary which then can be eliminated from storage.

It all depends on your setup.


Forum|alt.badge.img+3

We have over 750 of these orphaned snapshots when running the query. Trying to slowly work through so that we only have more updated snapshots will take a lot of time. Thank you for all of the help!

-Andrew


dude
Byte
Forum|alt.badge.img+15
  • Byte
  • 287 replies
  • August 26, 2021

You bet. We have netapps all over and I know exactly what you mean, so dont hesitate if you need help.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings