Getting backup size via VBR API v11

[claygod]

Hello!

Through the application, you can get information about the Backup Size of restore points
(https://helpcenter.veeam.com/archive/ba ... rties.html)

Tell me, is it possible to get such information through the VBR API version 11.0?
(https://helpcenter.veeam.com/archive/ba ... -rest.html)

[oleg.feoktistov]

Hi,

Not possible with VBR REST in v11 as we haven't exposed backup files there yet.
But I noted your question as a feature request.

Best regards,
Oleg

[claygod]

Oleg, thanks for the quick response!

Let me clarify: is this also impossible through the VBEM API (when it interacts with vSphere)?

[oleg.feoktistov]

Hi Eduard,

In EM REST API it's possible:

1. Obtain a backup with GET /backups/{ID}.
2. Query its backup files using the link of BackupFileReferenceList type.
3. Get backup files specs in a list using Entity formatting. Example:
https://localhost:9398/api/backups/{id} ... mat=Entity
4. Count the sum of BackupSize values for each backup file.

For a list of available properties for backup files check this article.

Best regards,
Oleg

[Erwin Linker]

Hi,

Can somebody tell me if it is possible to read the back-up size trough, VBR REST 1.1-rev1 ?

Regards,
Erwin

[oleg.feoktistov]

Hi Erwin,

No it's not. But noted as an enhancement request.

Thanks,
Oleg

[Erwin Linker]

Hi Oleg,

There is almost a year passed, when will it be added? We want to migratie the API from VEM to VBR.

Regards,
Erwin

[oleg.feoktistov]

Can't give you any precise ETA. Possibly this year. Thanks!

[Erwin Linker]

Last question .

The idea is that the VBR API will replace the VEM API?
Thats the reason why we are exploring the VBR API. And that we can restore a VM to a specific datastore with the VBR API.

Is there a roadmap for the development of the VBR API, so that we can plan resources for the development when it is ready.

[oleg.feoktistov]

The idea is that the VBR API will replace the VEM API?

Correct, that is the goal.

Is there a roadmap for the development of the VBR API

There isn't a public one, no. But if you are interested in a specific feature/set of features that would easen transition from EM REST to VBR REST for you, please ask here/let me know. Reporting on backup sizes in particular is planned for one of the vNext releases (this year).

Best regards,
Oleg

[squebel]

Oleg,

We have some extensive coding built around pulling backup information from the VEM API so this worries me to read that Veeam may be moving away from that API altogether. We aggregate about 15 VBR servers to a main VEM server so we have one endpoint to hit for all the backup information across all our environments and clients. Am I reading that that might not be an option in the future? Or am I misunderstanding something?

[jorgedlcruz]

Hello squebel,
Have you considered moving that extensive coding to VeeamONE API?
The Veeam ONE API has this data and much more due the nature of the product, I have been personally involved in a huge moves from EM APIs, or PowerShell to VONE API.

Take a look at the map to see how many endpoints we have today, and any questions please ping me via dm, or on the VONE forums.

https://www.veeam.com/veeam_one_12_2_re ... map_ot.pdf

Thank you!!

[squebel]

Thanks for the reply, Jorge. So the problem with VeeamONE is that it is expensive. It is an additional cost that we don't really need. Also, we've had it in the past and found it just not be very stable and had a lot of issues with it. That's a separate subject.

I would still like to understand the future of VEM. Maybe that is something I can take up with my account team?

[oleg.feoktistov]

We have some extensive coding built around pulling backup information from the VEM API so this worries me to read that Veeam may be moving away from that API altogether.

Allow me to clarify. We decided to stop enhancing VEM REST API in favor of VBR REST API. That doesn't mean that we suddenly don't support VEM API anymore - you absolutely can submit a ticket or a private fix request and continue to use supported VEM API versions. We also continue to provide bug fixes if applicable. Discontinuing it altogether before providing an alternative, I believe, would be a tough breaking point. One of the ultimate goals would be to avoid that. I'd say VBR REST API could be a fundament for this alternative, but it's still to be discussed.

Best regards,
Oleg