Conditions for generating each status returned in the powershell execution result

[yokokazu]

We are a service provider looking to implement Veeam for our backup services.
Currently we are planning to develop a custom portal using RestAPI and PowerShell (PS for covering operations that cannot be performed with RestAPI).

Regarding Job/Task state values listed in the help, there are very little information.
https://helpcenter.veeam.com/docs/backu ... ssionstate

It is mandatory for us to know the conditions where the each states occurs for developing the custom portal and replacing exisiting backup product. We use it for error handling,too.

Could you give us a little more information for each of states?

[Current setup/scope]
* vSphere Backup Job only (No File Backup Job/Copy Job/Replication Job)
* Win/Linux Repos or Dedup Repo (No tape)

[States in the help guide and our assumption]
ActionRequired : This is for VeeaMover tasks. Never occur in backup job.
Idle : This is only for replication job. Never occur in backup job.
Pausing : This is only for copy job. Never occur in backup job.
Pending : This is only for copy job. Never occur in backup job.
Postprocessing : This occurs when merge/synthetic full happening.
Resuming : This is only for copy job. Never occur in backup job.
Starting : This occurs when the job is started and before becoming working state.
Stopped : This occurs when the job is completed.
Stopping : This occurs when the job is mannualy stopped.
WaitingRepository : Don't know when occurs but Never occur in backup job.
WaitingSlot : This is only occurs when tape job used. Never occur in backup job.
WaitingTape : This is only occurs when tape job used. Never occur in backup job.
Working : Backup Job uses this state for processing.

If the support case is preffered way, please let us know.

Best Regards,
yokokazu

[HannesK]

Hello,
and welcome to the forums.

I'm not sure, what the real question is. As far as I see, the text you copied from the user guide explains each situation. Which situation is unclear? Most results are irrelevant anyway, because they don't match your scenario (you only have backup jobs. no tape or copy jobs)

Best regards,
Hannes

[yokokazu]

Thank you for your response, Hannes.
Regarding the scope of the backup service, Backup Copy may be used in the future, so let me modify it as follows.
[Setup/scope]
* vSphere Backup Job only and Backup Copy Job (No File Backup Job/Replication Job)
* Win/Linux Repos or Dedup Repo (No tape)
The description for each state in my first post are our assumptions and there are no such description in the help.
What we wanted to know was;
*Which states we don't need to consider? (States that do not occur in our environment)
*What are the conditions for the states that need to be taken into account to occur?
　e.g. Postprocessing state occurs when merge/synthtic processing is being performed.


At the custom portal
View the status of Backup Job or Backup Copy Job for your virtual machines,
In order to be able to handle the following,
I have confirmed.

・Judgment of queuing before execution of backup and restore processing, execution, normal end, abnormal end, cancellation, prevention of duplicate execution, etc.
・Whether it is possible to turn on/off the power of the virtual machine
・Whether it is possible to create/restore/delete snapshots of virtual machines (vmware snapshots)

Thank you in advance.

[david.domask]

Hi @yokokazu,

I'm afraid that it's not going to be possible to define every single scenario that may lead to such a status. Since these are all possible return values, your code should be prepared to handle all of them, even if _likely_ a feature is not used by your clients who connect. You can never really know I suppose.

With the exception of Action Required, all of the statuses are quite straight forward, but we cannot tell you for example every reason a repository might be out of concurrent tasks and the job needs to wait; instead, you just should write handling for each of the statuses and decide how you want to respond: instruct the portal user to just wait, send an internal issue alert if the status stays like that for N hours, etc. It's really your choice.

So I would say you must accommodate for all statuses, as your users may surprise you. As for how each condition might happen, I'm afraid there are simply too many possibilities for each status, and instead it's better to just understand that the status is telling you something as outlined in the linked User Guide, and you will need to decide how to take action.

> ・Judgment of queuing before execution of backup and restore processing, execution, normal end, abnormal end, cancellation, prevention of duplicate execution, etc.

Maybe I'm reading this part wrong or misunderstanding you, but it really sounds like you're trying to write your own scheduler for the jobs. I really do not recommend this, schedulers are complex. VBR already has a built-in scheduler, so it should be fine to just let the jobs run on their schedule, no need to worry about duplicate execution etc. If you want to provide Self-Service functionality, you can do so with Enterprise Manager and the Self-Service Portal: https://helpcenter.veeam.com/docs/backu ... ml?ver=120

I honestly think this will save you a lot of time, and you can build your custom portal based off the Enterprise Manager RestAPI; the statuses should mostly be the same, and you can get the information without having to worry about users triggering jobs incorrectly as the portal handles job scheduling and also allows for one-off backup tasks.

I really think that a combination of RestAPI + Enterprise Manager is a better option for you.

[oleg.feoktistov]

Adding to David's comment, I would also recommend looking towards REST APIs when building a custom portal as 1) It's more web-oriented, 2) our Powershell still contains many internal classes and methods that might give you the detailed info you seek, but are very unreliable in terms of compatibility, 3) Powershell module has no versioning. So if something breaks in internall classes that are publicly exposed, you will be forced to rewrite the changed part in your portal code. Thanks!