Backups based on Backup Groups fail suddenly (4046843)

Backups based on vRanger Backup Groups start failing after ESXi updates (host-side storage changes/host rebuilds/Virtual Center rebuilds)

vRanger's functionality is based upon a system of cross-indexed UUIDs (unique identifiers) that is constructed from the UUIDs created by the Virtual Center database and/or ESX(i) host. Altering/upgrading storage, for example on the ESX-side (like moving datastores/VMs to a new SAN) can cause the association in the vRanger database to "break", since the new datastore (even if named the same as before) will be assigned a new UUID by VMWare. In this case, vRanger does not assume that the name being the same means this is the same datastore, so it can "lose" the location of the VMs in the Backup Group. Thus, the backup group shows no VMs present, even though they still appear in the vRanger inventory normally.

1) "Edit" the Backup Group(s) that the backups are based from (NOT the backup jobs).

2) Re-select the VMs that should be in the Backup Group (they will not be "checked" as they should be). This will re-point the group to the proper VMs, and fix the "lost UUID" problem.

3) Apply the changes and expand the Backup Group in the Backup Group section of the Inventory screen.

4) The valid VMs will show alongside the "orphaned" ones with the faulty (i.e. no longer extant) UUID information. The valid VMs will have a VMware "three blue boxes" icon next to them. The invalid ones will not.

5) Right-click the invalid entries and remove/delete them from the Backup Group. This will purge them from the vRanger database

Since the backup jobs are based on the backup groupings, this method will allow you to correct the problem without having to recreate the backup jobs themselves. Once the Backup Groups are back in order, backups should proceed normally.