BackupJobSessions are empty after update to v12

[marijana_pae]

Hi,

I have some troubles with REST API after update to v12.

Before, on v11 if I use filter like

Code: Select all

'JobUid=="<valid_job_id>"'

with

Code: Select all

/api/query?type=BackupJobSession

(and few more parameters) I would get list of sessions under BackupJobSessions.BackupJobSessions

Now, after update, expected list is always empty.

Can you confirm if this is some change within v12, and how should I get list of sessions now?

Thanks

[oleg.feoktistov]

Hi,

Works for me in v12. Are you supplying JobUid in urn:veeam:Job:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX format?
What are the other parameters that you use?

Best regards,
Oleg

[marijana_pae]

Hi Oleg,
Thank you for your reply.

No, we are supplying JobUid in XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX format.
The reason for this was NAS jobs.
For NasJob job types UID is "urn:veeam:NasJob:XXXXXXXX...".
If we are using that UID we get '400 BadRequest' with msg 'Entity Uids are invalid: [Job,AgentBackupJob]'
If we use only numeric part of UID than we used to get data.
I don't know if that is still valid.

Other parameters are page, pageSize, format=Entities, sortDesc=CreationTime

Help is really appreciated.
Thanks.

All best,
Marijana

[oleg.feoktistov]

Hi Marijana,

What happens if you use urn:veeam:Job formatting instead of urn:veeam:NasJob ?
I tried it with both urn:veeam:Job and just the id in v12, the query worked fine. So, your issue doesn't look expected to me.

Best regards,
Oleg

[marijana_pae]

Hi Oleg,

Sorry for delay in writing back.

At the moment I have v11.
Using only numeric part of uid works. That I expected to work.
Also using urn:veeam:Job works. I must say that I don't like this solution since originally UID is urn:veeam:NasJob:xx..xx

At the moment I can't test it with v12, but you can verify from your tests that using only numeric part of NAS UID works also for v12?
For example:

Code: Select all

https://{{device}}/api/query?sortDesc=CreationTime&pageSize=25&type=BackupJobSession&format=Entities&page=1&filter=JobUid=={{nas_uid_numeric_part}}

Looking forward to your answer.

All best,
Marijana

[oleg.feoktistov]

Hi Marijana,

I must say that I don't like this solution since originally UID is urn:veeam:NasJob:xx..xx

Yes, BackupJobSessions query doesn't support NasJob type. It would probably require a separate query for NAS.

but you can verify from your tests that using only numeric part of NAS UID works also for v12?

Correct. I would suggest to contact support and let them investigate. Troubleshooting capabilities through forums are really limited.

Best regards,
Oleg

[marijana_pae]

Hi Oleg,

You are right about NasJob sessions, they are returned with both urn:veeam:NasJob:XXXXXXXX... and XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX format on v12.

Nevertheless, there is an issue with sessions from job type "ImmediateBackupCopy".

So if I ask for sessions on job which type is 'copy' I don't get any sessions, even if I know there is some.
Same parameters as before, there is no sessions no matter which format of UID is used.

I will try to open a ticket but any help from forum is also much appreciated.

Have a great day,
Marijana

[oleg.feoktistov]

Hi Marijana,

Glad it works for nas jobs. As for ImmediateBackupCopy, looks like there was a bug that has been fixed in post-v12 dev builds.
For v12 try to query by ImmediateBackupCopyWorker type.

Best regards,
Oleg

[marijana_pae]

Hi Oleg,

Thank you so much for your answer.
I guess I will wait until fix is publicly available.
Do you know when it's expected to have this fix/patch published?

Thank you again,
You helped me a lot.
Very appreciated.

All best,
Marijana

[oleg.feoktistov]

Hi Marijana,

Most likely the fix won't make it to the next patch for v12, but it's going to be a part of the next product version (12a).
Can't share any ETA on v12a though.

Best regards,
Oleg

[marijana_pae]

Hey Oleg,
Can you also give the ticket/bug ID where this issue is tackled?

Thanks,
Best regards,
Marijana

[oleg.feoktistov]

Hi Marijana,

We don't have any public id on such issues available, only the ones for internal tracking.

Best regards,
Oleg

[marijana_pae]

Hi Oleg,
Thank you for fast response.

The thing is that I have customer who contacted Veeam Support regarding the same matter. And now they are asking me for ID.
I already told my customer what you told me here, that fix is probably going to be available in v12a.
But looks like my customer wants to know more, that must be the reason why they contacted them anyhow.

Best regards,
Marijana

[oleg.feoktistov]

Hi Marijana,

Sorry for the delayed response. Looks like a very similar issue was originally reported in case 06008693, so a bug was submitted. Later on, it turned out that our developers fixed it proactively before, which also impacted the behaviour you reported as these issues are interconnected. As I checked, the fix is in the most recent dev builds, so it should be a part of vNext release.

Best regards,
Oleg

[marijana_pae]

Ho Oleg,

Thank you so much for info.
I really appreciate it.

Best regards,
Marijana