Solved

API to launch backup job


Badge +7

Hi All,

 

I am baffled by why I have same API working on commserve and on another I get Internal Server Error (500)..

 

I am trying to launch a backup job, using same api request and get different outcome on 2 commserves…
 

api request

 
Here you can see in red there is the api request if application is Virtual Server - this is failing with 500.

output


Another which is File System - completes ok. For SQL also completes ok..
 

 

I’ve tried different backup levels thinking maybe there is some kind of thought behind it.. looked into documentation here: https://documentation.commvault.com/v11/essential/45793_rest_api_post_backup_set_backup.html

Following that I’ve changed headers to application/xml instead of /json - but still the same… Logs from the failing commservs webserver.log:

webserver.log


Any ideas on this one?

icon

Best answer by benjaminas 21 June 2022, 11:14

View original

23 replies

Badge +7

Found this in the log as well:

 

webserver.log

 

Userlevel 4
Badge +11

@benjaminas 

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

Badge +7

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

Userlevel 4
Badge +11

@benjaminas

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

Badge +7

@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.

Userlevel 4
Badge +11

@benjaminas 

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

Userlevel 4
Badge +11

@benjaminas 

Instancename is wrong please try VMware and see if that works

Badge +7

@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.

Userlevel 4
Badge +11

@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.

 

Badge +7

@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 subclient['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)

 

Userlevel 4
Badge +11

@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

 

instanceName

Name of the instance that contains the subclient. By default this value is VMware.

associations

 

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

Userlevel 5
Badge +16

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.

 

 

 

 

Userlevel 5
Badge +16

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

 

 

 

Userlevel 5
Badge +16

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.

Badge +7

@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:
 

subclient id based api request



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:
 

issue at webserver.log


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

Userlevel 7
Badge +19

@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?

Badge +7

@Onno van den Berg 

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

Userlevel 7
Badge +19

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. 

Badge +7

@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

v11.24


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

 

v11.25

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:

QSDK

 

Userlevel 7
Badge +19

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. 

 

Userlevel 5
Badge +16

@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:
 

subclient id based api request



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:
 

issue at webserver.log


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.

 

Badge +7

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

 

Userlevel 7
Badge +23

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

Reply