LastBackupStatus of a VM

[riccardomoschetti]

Dear all,
I am trying to use the RESTful API of Veeam to get a list of the last backup status and date for each VM.

By following this post (restful-api-f30/relate-vm-objects-to-jobs-t62760.html) it looks like the information I need shall be found with /query?type=VmRestorePoint, under "CreationTime" (meaning that a backup of a VM was successful, I would find a RestorePoint).

Unfortunately that seems not to be the case: I tried with
/api/query?type=backupjobsession&format=entities&filter=EndTime>="2021-01-01 12:00:00"&sortDesc=EndTime&pageSize=15&page=1,
but the response is empty (with status 200): it seems like the only Restore Points I am able to find coincides with the original creation of the backup job.

NB: I am sure that a backup was made in 2021, since I am able to find it using Veeam One Reporter. In general, it seems that using the REST API, I am able to find all jobs and VM in the system, but not the status of the last backup.

Could you help me in figuring out what I am doing wrong?

Thank you very much,
Riccardo

[chris.arceneaux]

Hi Ricardo,

Welcome to Veeam forums! As you just want the last backup status and date for each VM, the below API calls will get you what you want.

Job Status

• Retrieve Backup Jobs
  • GET /api/jobs
• Retrieve Backup Sessions
  • GET /api/query?format=Entities&sortDesc=CreationTime&type=BackupJobSession
  • Sorted Newest to Oldest
  • JobUid ties the Backup Session --> Job
  • The most recent session will provide you with the current state of the Backup Job.
• Retrieve Backups Task Sessions
  • GET /api/query?format=Entities&sortDesc=CreationTime&type=BackupTaskSession
  • Sorted Newest to Oldest
  • Here's where you're getting to the VM-level. VmUid is the unique ID for a specific VM. Much better than using VM Name.
  • JobSessionUid ties the Backup Task Session --> Backup Session --> Job

[riccardomoschetti]

Dear Chris,
Thank you very much for your answer: it made very clear where to search for the difference between BackupJobSession and BackupTaskSession.
And also thank you for the welcome in this community!

I tried the request you suggested and they indeed fit with what I am trying to find.

There is something I cannot explain (which is the reason why I got confused in the first place).
I run the request you suggested

• GET /api/query?format=Entities&sortDesc=CreationTime&type=BackupJobSession

It should return as you explained to me, the list of BackupJobSession, ordered by Creation time. Now In this list I look for a certain job (say "Job1").

I know from Veeam One Reporter that "Job1" had a LastRunStartTime "Jan 9 2021 4:00PM" (I create a custom report with jobs and LastRunStartTime), so I would expect to find it in the response of the API with the same date in CreationTimeUTC.
Unfortunately, that is not the case: "Job1" appears n the response many times, but the most recent CreationTimeUTC is "2020-03-28T16:45:10.393Z".

Actually, the most recent CreationTimeUTC in the whole list returned by the API appears to be "2020-03-29T01:30:22.983Z", and I am pretty sure I am not missing results (there is only 1 page, and there was the parameter sortDesc=CreationTime).

The same happens for the query "BackupTaskSession": despite the fact that Veeam One reporter shows tasks which have been completed yesterday, the most recent element has CreationTimeUTC "2020-03-29T10:12:38.05Z".

Do you have any idea about why this can be happening? I am sure that the server reference is ok, so I have no other explaination.

Thank you very much again,
Riccardo

[chris.arceneaux]

Seems like your Enterprise Manager server doesn't have the most up to date information for the Veeam Backup & Replication server it's managing. I recommend you open a support case to ascertain the source of the issue.

[riccardomoschetti]

I contacted the support as you told me and in fact there was an error in the Enterprise Manager server. This was preventing the update of the response of the API.
After an update now it works perfectly, and I can confirm that the queries suggested by Chris works exactly as intended.

Thank you very much again,

Riccardo