Seemingly random failures occur in some backups with the above error. Backups working fine one day, then inexplicably fail the next, etc.
The Inventory database in vRanger may have become corrupted, or may have "stale" Virtual Center/ESX(i) Host information in it (after an upgrade/rebuild of the Virtual Center server, for example.). Rebuilding VMware-side components of the environment may re-assign new UUIDs (Unique Identifiers) to ESX hosts/datastores/VMs. These "new" UUIDs, even if they are indexing the same machines, etc. as they did before, no longer match the UUIDs vRanger is expecting these components to have the same UUID value as in the inventory check. Thus, when a backup job starts, and the Inventory Database is polled to see the location of hosts/VMs/Datastores, the query can be attempting to find a UUID that is no longer valid. The query will run with no return until the query timeout period is reached, then fail with the above error.
1) Launch the Startup Wizard (Tools--->Startup Wizard).
2) REMOVE the Virtual Center from the second screen. DO NOT re-add it yet.
3) Also REMOVE the ESX(i) HOSTS from this screen. You may see "disconnected" or otherwise "phantom" host(s) in the inventory after the Virtual Center component is removed. These illustrate the "stale" UUIDs that vRanger has "stuck" in its database.
4) Close the wizard and the vRanger GUI. Re-launch the GUI, and re-launch the Wizard.
5) Re-add the Virtual Center and Hosts(if using host credentialing as well as VC-based credentialing)
6) Check the scheduled backup jobs. Occasionally, some jobs may be broken and need to be reconstructed (they usually will show in the "disabled" jobs folder). If they are not disabled, "Edit" a scheduled job. If the inventory can "see" the VM(s) in the job and they are listed on the second screen in the exclusion list, the job is more than likely fine.
7) Run the job if it "passes the test" in step #6. If it does not appear as expected in step #6, recreate a new job to test a VM that had previously failed. The job should now run normally, and reconstruct backup jobs as needed.
NOTE: This is one possible cause of this issue; others may also exist.
