Skip to main content
Solved

Delete snapshot from Array Management


Forum|alt.badge.img+7

Hi guys, do you know how to fix this thing? I want to delete snapshots manually from array management and get this error...

Error Code: [19:2018]
Description: Workflow [Snap-UserOperations] completed with one or more errors.
Source: xxx, Process: Workflow
No Host found with HostId [10633]. Failed snap volumes will be handled later by the automatic clean up process.
Source: xxxx, Process: Workflow


I ran the data aging (i think this the forementioned ‘automatic clean up process’) - nothing changed...

Best answer by tph

I would recommend you to open a support ticket to further investigate your issue. 

“If I use force delete - will aux copy then ignore those bad jobs of why it is failing and should complete?” Yes since that will remove it from the CS Database, BUT I would look at the job itself first (2478095) where you can perhaps select as Do Not Copy and achieve the same goal.

The snapshot SP_2_2478095_1651721277 is probably part of the selection for the AUX Copy that commvault has in its database. I can not recommend you to delete or not a snapshot without a proper understanding of your enviroment. I can say that from what you are explaining it looks like the snap SP_2_2478095_1651721277 is causing the issue and you could try the Do Not Copy on that particular job. 

Make sure the Aux Copy is not running, then kick it again, commvault will pick the subsequential one for the AUX.

 

View original
Did this answer your question?

13 replies

Forum|alt.badge.img+5
  • Vaulter
  • 33 replies
  • May 19, 2022

Hi,

 

I would make sure the volume that holds the snap is online. If it is online, make sure that the snaps listed for the volume match Commvault because when they dont, it sort of means that someone deleted them manually and commvault can`t locate the snaps.

Also, it could be that the job in question has its retention extended, so check the job in question as well.

There is also an option to Force Delete that can be executed then you can run data aging and wait a few mins then check again.

Tks

 


Forum|alt.badge.img+7
  • Author
  • Byte
  • 37 replies
  • May 19, 2022

Hi @tph ,

 

Force delete sounds aggressive, are there any downsides to it if I do it that way?


Forum|alt.badge.img+5
  • Vaulter
  • 33 replies
  • May 19, 2022

Right, I mentioned the “Force” after checking and making sure that a few other spots were ok. Go through the array lilke I said, also make sure the media agent can communicate with the array.

Could be mismatch, communication etc. 


Forum|alt.badge.img+7
  • Author
  • Byte
  • 37 replies
  • May 19, 2022

@tph Let’s assume all above are OK and still they are present and I need to remove them. If I use ‘Force’ - what problem could I face?


Forum|alt.badge.img+5
  • Vaulter
  • 33 replies
  • May 19, 2022

Let`s not assume 😀 

Force delete will completely remove the snapshot entry from CS Database. Please review the below link

https://documentation.commvault.com/11.24/expert/36922_force_deleting_snapshots.html


Forum|alt.badge.img+6
  • Commvault Certified Expert
  • 40 replies
  • May 19, 2022

Most of the time the the snapshot is been still mounted, as example on a ESXi host. Then both procedure could fail from the array perspective (i have seen in on a Pure array) because its still mounted. By unmounting it from the array the snaps can be removed from Commvault perspective.

i have seen this on 11.26 for the Pure, and knows after contacting support they have a DIAG fix ready for this.


Forum|alt.badge.img+7
  • Author
  • Byte
  • 37 replies
  • May 19, 2022

@tph @M Scheepers 

Force delete will not delete from array, but simple delete will delete from array together with cs db?

Problem I have why I need to delete ‘bad’ snapshots is that our aux copy is not working..

·  ERROR CODE [13:226]: Error occurred while replicating snaps [ x:SP_2_2478095_1651721277], for storage policy [SP-HAN-VM_Snapshot_30days-02] copy [2. Secondary Snapshot] MediaAgent [x]: Backup Job [2478567]. Failed to create replica snaps for primary snap job[2477371] [Failed to prepare snapshot.].
Source: x, Process: CVJobReplicatorODS

Failed to prepare snapshot. : [No relationships found that can be used to replicate snapshots on file server:[x] for source volume:[x].Please create a valid relationship if one doesn't exist or wait for data transfer to complete before retrying the operation.If SVM mapping is configured on secondary snapshot copy, file server relationship must conform to the mapping.]
Source: x, Process: CVJobReplicatorODS

 


Forum|alt.badge.img+5
  • Vaulter
  • 33 replies
  • May 19, 2022

The error makes it looks like you need a relationship between the two storage arrays. Can you check with your storage team if there is a relationship in place?

This post is sort of going to a different direction now. 


Forum|alt.badge.img+7
  • Author
  • Byte
  • 37 replies
  • May 19, 2022

@tph 

 

Due to our setup we will not add additional relationships between SVMs. This is the problem caused by our cloud team where they provisioned additional disks from different datastore and thus VM has disks from 2 different datastores and hence the error above. I need to delete the snapshots as we will not change relationships.


Forum|alt.badge.img+5
  • Vaulter
  • 33 replies
  • May 19, 2022

With the information you provided I will make a wild guess here. It seems like you have a AUX Copy that you no longer need and therefore deleted the relationship between the SVMs.

Commvault keeps track of that relationship on its database. If Commvault can not communicate with the Array it wont be able to delete the snapshot. It will most likely have to be removed manually (snapshot delete command) on your storage side.

As for the Commvault info, there is a Report that you can install and download so you can clean up the relationship from the CS Database and the error complaining about the relationship should go away. 

Follow: https://documentation.commvault.com/11.24/essential/104070_viewing_netapp_open_replication_relationship_information.html

 

The force option will clean up the snaps from CS Database but wont clean up the snaps from the array as explained above.


Forum|alt.badge.img+7
  • Author
  • Byte
  • 37 replies
  • May 19, 2022

@tph 

Nope.

 

Again, we have few backup jobs which backed up VM which was on more than 1 datastore at the time, that is why aux copy is failing with relationship problem. I want to delete those incorrect backup jobs, because I actually NEED aux copy to run. Those few jobs are failing whole aux copy job. So nonetheless..out comes the following question:

If I use force delete - will aux copy then ignore those bad jobs of why it is failing and should complete?


Forum|alt.badge.img+5
  • Vaulter
  • 33 replies
  • Answer
  • May 19, 2022

I would recommend you to open a support ticket to further investigate your issue. 

“If I use force delete - will aux copy then ignore those bad jobs of why it is failing and should complete?” Yes since that will remove it from the CS Database, BUT I would look at the job itself first (2478095) where you can perhaps select as Do Not Copy and achieve the same goal.

The snapshot SP_2_2478095_1651721277 is probably part of the selection for the AUX Copy that commvault has in its database. I can not recommend you to delete or not a snapshot without a proper understanding of your enviroment. I can say that from what you are explaining it looks like the snap SP_2_2478095_1651721277 is causing the issue and you could try the Do Not Copy on that particular job. 

Make sure the Aux Copy is not running, then kick it again, commvault will pick the subsequential one for the AUX.

 


Forum|alt.badge.img+6
  • Commvault Certified Expert
  • 40 replies
  • May 20, 2022

hi @benjaminas,

as @tph is suggesting you should then remove the “incorrect” jobs from the backup copy list. This prevents further issues while running the AUX copies.


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