SMVI 2.0 - Cleaning up "zombie" backups & mounts on volumes that no longer exist on the NetApp controller??

[orourke]

Is there a "hidden" -force option on the "smvi backup delete -backup-name ......." or "smvi backup unmount -backup-name....."  commands????

The volumes that were actually backed up / mounted were deleted from the NetApp controller before being cleaned-up in SMVI.  Now we have "zombie" backups and mounts.

I just want to clean up the backup repository and get rid of stuff that no longer exists in the real world but SMVI thinks it still does.

[amritad]

Hi

Snapshot issue: IS this customer facing the orphaned snapshot issue? If that is the case we have a tool that can detect and clean up orphaned snapshots.

Here’s the link and blog to this

Matt Robinson, the creator of the SV-SMVI tool has made a little tool

to clean up orphaned VMware snapshots that SMVI may leave behind. I

blogged about the tool and provided soem sample SMVI scripts for it

here (http://bit.ly/bYv1bi) and the tool can be downloaded here

(http://communities.netapp.com/docs/DOC-4936)

Regards

Amrita

[orourke]

Amrita,

Thanks for the response.  Actually, I am looking to clean up the SMVI catalog (not the Virtual Center environment).  The SMVI catalog shows several backups that are mounted even thought the underlying NetApp volume does not even exist anymore.  I just want to clean up the SMVI catalog with the "smvi backup delete......" and "smvi backup unmount....." commands.   If I try to do this, I get messages that indicate issues with conecting to the volume (because it does not exist).

[amritad]

Hi

What happens when you try and unmount it directly from the ESX? Does that fail too?

REgards

Amrita

[orourke]

Thanks Matt and Amrita.

[orourke]

Actually,

I am looking for a tool that cleans out the "orphanded backups" from the XML catalog on the SMVI server.

Here is an example.....

1) You run SMVI to take a snapshot.....

2) Volume "autodelete" removes the snapshot from the volume.

3) The SMVI catalog (xml) still thinks the backup exists.  You cannot delete it from the catalog without "hacking' the XML catalog.

4) Is there a clean way to delete these backups from the SMVI catalog?

[mikesicarup]

I can't get to this link....do you have an updated URL?

[CIRAAMANDA]

I know this is late, but I recently got the fix for this myself and hope it might be useful for someone else searching for this later:

- stop the NetApp vSphere Plugin Framework service,

- stop the NetApp SnapManager for Virtual Infrastructure service

- copy the %install%/smvi/server/repository/backups.xml file

- use wordpad and edit the same file

- remove the backup entry from the "<backup uuid="" tag through to the </backup>

- restart the SMVI and NVPF services

- check and see if the backup still exists

[NTAPSUPPORT]

Even easier...

In vCenter – Home – Solutions and Applications – NetApp and select Backup and Recovery - and remove the failed job(s)

[framus]

Thanks, this is exactly  what I needed .

The even easier solution posted by NTAPSUPPORT would probably work as well, if the job is actually listed in VCenter.

[dburklan]

This is great and worked like a charm, even for VSC 5.0 in my lab, thanks!

Dan

[Bektas_Denmark]

Thanks !!!

I had a similar problem. One of my customers is using SMSQL against NFS volumes.

Without reason SMSQL started having trouble backing up the SnapInfo volume. I wasn't able to create new snapshots using named sqlinfo__XXX__recent using SMSQL / SnapDrive. I just got an error telling me that the snapshot name already existed. It didn't on the filer / SnapDrive / SMSQL.

I tried almost everything including reinstalling SD/SMSQL but nothing worked until i found this post. The problem I had looked like this:


The complete operation list is shown as follows
Server Name: *********************


1. Preparing LUNs for Snapshot copy creation

2. Creating a Snapshot copy for the LUN

3. Creation of backup (sqlinfo__XXX__recent) failed.
 Reason: (The backup or job name sqlinfo__XXX__recent already exists. Names must be unique.).


When editing the XLM file I found an entry with the snapshot name. The status of the job was u"running". Deleting this entry solved the problem.