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

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

Regards,

Rashid

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.

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

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.

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

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.

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

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