The Story

There’s been a couple time where my VM-IS’s change:

• A vSphere server has crashed beyond a recoverable state.
• A server has been removed and added back into the inventory in vSphere.
• Manually move a VM to a new ESXi host.
  • VM removed from inventory, and readded.
• Loss vCenter Server.
• Full VM Recovery via Veeam.

What sucks is when you go to run the Job in Veeam after any of the above, the job simply fails to find the object. You can edit the job by removing the VM and re-adding it, but this will build a whole new chain, which you can see in the repo of Veeam after such events occur:

As you can see two chains, this has been an annoyance for a long time for me, as there’s no way to manually set the VM-ID in vCenter, it’s all automanaged.

I found this Veeam thread discussing the same issue, and someone mentioned “an old trick” which may apply, and linked to a blog post by someone named “Ideen Jahanshahi”.

I had no idea about this, let’s try…

Determine VM-ID on vCenter

The source uses powerCLI, which I’ve covered installing, but easier is to just use the Web UI, and in the address bar grab it after the vms parameter.

Determine VM-ID in Veeam

The source installs SSMS, and much like my fixing WSUS post, I don’t like installing heavy stuff on my servers to do managerial tasks. Lucky for me, SQLCMD is already installed on the Veeam server so no extra software needed.

Pre-reqs for SQLCMD

You’ll need the hostname. (run command hostname).

You’ll need the Instance name. (Use services.msc to list SQL services)

Connect to Veeam DB

Open CMD as admin

sqlcmd -E -S Veeam\VEEAMSQL2012

use VeeamBackup
:setvar SQLCMDMAXVARTYPEWIDTH 30
:setvar SQLCMDMAXFIXEDTYPEWIDTH 30
SELECT bj.name, bo.object_id FROM bjob bj INNER JOIN ObjectsInJobs oij ON bj.id = oij.job_id INNER JOIN Bobjects bo ON bo.id = oij.object_id WHERE bj.type=0
go

Some reason above code wouldn’t work on my latest build/install of Veeam, but this one worked:

SELECT name, job_id, bo.object_id FROM bjobs bj INNER JOIN ObjectsInJobs oij ON bj.id = oij.job_id INNER JOIN BObjects bo ON bo.id = oij.object_id WHERE bj.type=0

In my case after remove the VM from inventory and readding it:

As you can see they do not match, and when I check the VM size in the job properties the size can’t be calculated cause the link is gone.

Fix the Broken Job

UPDATE bobjects SET object_id = 'vm-55633' WHERE object_id='vm-53657'

After this I checked the VM size in the job properties and it was calculated, to my amazement it fully worked it even retained the CBT points, and the backup job ran perfectly. Woo-hoo!

This info is for educational purposes only, what you do in your own environment is on you. Cheers, hope this helps someone.

Postgres SQL

Step-by-Step: Find and Connect to the Right Database

1. List All Databases

Inside the psql shell, run:

\l

This will list all databases on the server. Look for one that resembles VeeamBackup, veeam_db, or something similar.

2. Connect to the Veeam Database

Once you identify the correct name, switch to it:

\c VeeamBackup

(Replace VeeamBackup with the actual name if different.)

3. List Tables

Now that you’re in the right database:

\dt *.*

This will show all tables across all schemas.

SELECT bj.name, bj.id AS job_id, bo.object_id
FROM bjobs bj
INNER JOIN ObjectsInJobs oij ON bj.id = oij.job_id
INNER JOIN BObjects bo ON bo.id = oij.object_id
WHERE bj.type = 0;

UPDATE BObjects SET object_id = 'vm-62' WHERE object_id = 'vm-24';