API to launch backup job

Found this in the log as well:

 

@benjaminas 

What is App_name that is being passed that is there the issue is.

@HolowEd ‘Virtual Server’ - it’s in the screenshot :)

@benjaminas

When you look at the logging in webserver server log, I am seeing virtual%20server instead of virtual server. 

@HolowEd this %20 is a character for space:

A space is assigned number 32, which is 20 in hexadecimal. When you see “%20,” it represents a space in an encoded URL, for example, http://www.example.com/products%20and%20services.html.

This change is being done by commvault in process of the api request.

@benjaminas 

Do you see the same %20 in web server log when for the File System backup which is working. Just want to verify.

@benjaminas 

Instancename is wrong please try VMware and see if that works

@HolowEd - instance name is not used in the api request as a parameter therefore it should make no impact here. Also the instance name is a value returned by commvault api for subclient details. Every value which is present is actually obtained from commvault itself.

@benjaminas 

If you supply the name it will override the default and use what is provided.  Please replace VMInstance with VMWare and this call should work or remove it from the call.

@HolowEd 

but again - I don’t use the VM instance anywhere in the api request, so should not matter what it actually is, right?

            if 'Virtual Server' in subclienti'appName']:
                response = requests.post(url + f"/Subclient/byName(clientName='{client_name}',appName='{app_name}',backupsetName='{backupset}',subclientName='{subclient_name}')/action/backup", headers=headers, verify=False)
                if response.status_code == 200:
                    raw_data = response.json()
                    print(raw_data)
                else:
                    print(response)

@benjaminas 

I am looking into this more, as I have found this on our documentation;

https://documentation.commvault.com/11.24/expert/32449_parameters_for_command_line_backups_vmware.html

Which when you look at the call being made the instance name is not VMWare but rather VMInstance.

Honestly why do it at the backupset level?

Do it from the sub client level by sub client ID

https://documentation.commvault.com/v11/essential/45783_rest_api_post_create_task_backup_01.html

SubclientID obviates the need to traverse the client hierarchy and try to figure out the naming nonsense associated with that.

And you could find your target sub client using the sub client hierarchy api call.

Yeah based on what you posted you are just kicking off backups for everything in the backupset.

You can use this, and either save the requisite hierarchy information and use it is in your subsequent calls or iterate over the backupset members.

https://documentation.commvault.com/11.24/essential/48628_rest_api_get_client_hierarchy.html

I should probably be more clear. 

Hardcoding those elements into the URL just seems like a bad idea and prone to error.

You can programattically call those elements that you are currently typing out and use them in your rest call. 

or rather than having to reference every level in the backup hierarchy just to kick off a sub client backup.

Simply kick off the backup with the subclientID which implies every level in the hierarchy.

It’s simpler, and less prone to error.

@christopherlecky

I am not hardcoding anything I think. My call is using the values which I get and it has the same return values that all of the possible calls for backup launch would need. So let’s take even easier approach to run backup using subclient id without any xml as described here: https://api.commvault.com/#18843211-17ae-4f54-ad40-db38560c4121, so the call would be:

response = requests.post(url + f"/Subclient/{sub_id}/action/backup?backupLevel=Synthetic_Full&runIncrementalBackup=True&incrementalLevel=AFTER_SYNTH", headers=headers, verify=False)

and it fails again:
 

Now this call that you mentioned https://documentation.commvault.com/v11/essential/45783_rest_api_post_create_task_backup_01.html requires xml with tons of parameters such as drive id, media agent, drive pool, library - I don’t want to put any of these because it’s then not dynamic. Unless it picks everything automatically. As of this moment this call sounds like I not only need the same parameters that I use in my above call like:

appName="File System" applicationId="33" backupsetName="defaultBackupSet" clientName="client001" commCellId="0" subbclientName="default"

but also need to fill in xml with other details as drive id, media agent, drive pool, library..

I no longer think this is a problem with API call, but rather something with commserv itself:
 

Might as well get a support case created as this is heading nowhere.

@benjaminas which feature release are you running and have you applied the latest maintenance release already? you mentioned a difference in output while running your code against two different CommCells, right? have you checked if there is version difference?

@Onno van den Berg 

The one which is working - v11.24.48, the one which is not working v11.25.32

So there's you answer….. I would open a support ticket or in case you are not in a hurry wait until next week when the next maintenance release will become available which might address your issue. 

@Onno van den Berg 

Not really an answer..it would be if there is a documentation somewhere about changes in the API and what are those changes Because NOWHERE in the documentation about the API call to be used there is any change, does not matter which version.

https://documentation.commvault.com/v11/essential/49164_rest_api_post_subclient_backup.html

https://documentation.commvault.com/11.25/expert/49164_rest_api_post_subclient_backup.html

 

So is commvault then lacking in updating their documentation? If there are in fact introduced changes in API - the documentation was updated 2 years ago...same with api.commvault.com - nothing changed there and nothing mentioned about it.

By the way, QSDK log if anybody is interested:

Well there are 2 possibilities:

• You are running into a version specific software bug. Hence my suggestion to open a TR and/or wait for the next FR25 MR release to go public.
• They altered the behavior and forgot to make the changes in the documentation. Unfortunately I have to confirm that not everything is being documented properly. 

Even maintenance releases sometimes make changes to the current version and/or add functionality. So things can break or change. As for API behavior it should remain consistent and I would be surprised that they changed a current API method. They are actually implementing a lot of new (v3) APIs to the product, especially FR26 brings tons of new API methods. They are adding new ones and improving existing API calls to make it easier to consume them for customers as well.

So to come back to the issue your are running into → open a TR. 

@christopherlecky

 

I am not hardcoding anything I think. My call is using the values which I get and it has the same return values that all of the possible calls for backup launch would need. So let’s take even easier approach to run backup using subclient id without any xml as described here: https://api.commvault.com/#18843211-17ae-4f54-ad40-db38560c4121, so the call would be:

response = requests.post(url + f"/Subclient/{sub_id}/action/backup?backupLevel=Synthetic_Full&runIncrementalBackup=True&incrementalLevel=AFTER_SYNTH", headers=headers, verify=False)

and it fails again:
 

Now this call that you mentioned https://documentation.commvault.com/v11/essential/45783_rest_api_post_create_task_backup_01.html requires xml with tons of parameters such as drive id, media agent, drive pool, library - I don’t want to put any of these because it’s then not dynamic. Unless it picks everything automatically. As of this moment this call sounds like I not only need the same parameters that I use in my above call like:

appName="File System" applicationId="33" backupsetName="defaultBackupSet" clientName="client001" commCellId="0" subbclientName="default"

but also need to fill in xml with other details as drive id, media agent, drive pool, library..

I no longer think this is a problem with API call, but rather something with commserv itself:
 

Might as well get a support case created as this is heading nowhere.

I should have composed my initial response to you more clearly. 

I could not see where you where defining the values in the hierarchy, and since the prevailing assumption at the time was that one of the identifying elements were incorrect what I was suggesting is that you you use the client hierarchy api call, which would dump a list of the sub client ID’s 

You could then initiate the backup from the subclientID this way if the AppName or anything else was wrong it would not matter.

As far as that XML goes, like %99 of that xml is optional, you don’t need to define those they will use defaults, setting the XML values will override existing values. That is also my fault for not making that clear. 

I would ask you to post the complete script but as it stands you could do with redacting a bunch of the identifying information here.

Hi,

Update for anyone that was interested, or for myself in the future:

For agent based simple api for subclient id works as in the initial 1st message of this post.

Problem I had was with a backup launch for VM which is backed up in the subclient of vcenter’s connector in CV. So for virtual if you want to launch backup - you have to use GUID.
 

So basically 3 API calls to run a backup..

{{ServerURL}}/Client - this get’s you client id and more stuff if you need that.
{{ServerURL}}v2/vsa/hypervisors/{{clientId}} - this will get you the GUID of the client.

{{ServerURL}}/v2/vsa/vm/{{vmGuid}}/backup - this will run a backup…

https://api.commvault.com/#75d9ebe0-0745-4a50-a357-fee91b36e28f

Thanks for sharing, @benjaminas !  Are you comfortable marking your reply as the Best Answer?