In this post I will take a closer look at the available Backup (recovery) endpoints for the vCenter Server Appliance in version 6.7.
When revisiting a previous post on VCSA monitoring I wanted to add in some information about the backup schedule, i.e is the schedule enabled?, and some information on the latest backup run.
Backup information in the management interface (VAMI)
This info is accessible in the Management interface (VAMI) where we have the Backup section.
We can see that the backup is scheduled daily, the server where the backup is pushed to, and there’s a list of the previous backup jobs. This include information like the state and duration. All of this is information that can be interesting to show in a dashboard.
Backup information through the REST API
Now let’s head over to the API explorer and see how we can access this information. For more information on how to get familiar with the REST API of the VCSA check out this post where I go into more detail about the APIs.
There are mainly two (well actually three) endpoints which we will use to pull the information from the VAMI, /rest/appliance/recovery/backup/schedules and /rest/appliance/recovery/backup/jobs.
The first endpoint will give us information about the backup schedule
It includes both the location, the actual schedule and the parts that will get backed out. And if the schedule is enabled or not.
Create a schedule
Although not part of my initial use case of pulling data for use in a dashboard I wanted to mention the ability to schedule backups as well. This is nice if you already have automated your VCSA deployment.
You use the same endpoint, /rest/appliance/recovery/backup/schedule, but now with the POST method and the schedule details (location, credentials, recurrence etc) in a body that are sent with the request. Note that at the time of this writing the VCSA only supports one schedule.
There’s also the ability to update as well as delete an existing schedule, again the same endpoint but now with the PUT method for update or DELETE for, you guessed it, deleting a schedule.
Now let’s see how we can pull information about the actual backup runs.
Here we will grab the first one (they’re sorted so that the last job is listed first) and construct a query to the endpoint /rest/appliance/recovery/backup/jobs/“job-id” which gives details about that specific job
There is an endpoint to give even more details about a job, /rest/appliance/recovery/backup/job/details
Note that this list details about many jobs and the response can be quite big so if you want to use this it might be wise to filter it on the job id through the filer.jobs parameter
Run a backup
To create a backup job you use the same endpoint as before, /rest/appliance/recovery/backup/job, but now with the POST method and we alse need to provide the some details about the backup and the location and credentials
We can also verify in the VAMI
Although not something I’ll use in my specific dashboarding use-case, the ability to run a backup programatically is nice. Maybe you are testing something on a regular basis and want to backup first to be able to restore it later, or you want to create a first backup directly after deploying your VCSA.
There are a few other endpoints available as well that are out of scope of what I needed for my dashboard use case, but it might be something to check out in the future.
We have the /rest/appliance/recovery/backup/parts endpoint which can give information about what different parts are available and the size of them
There’s an endpoint for validating a backup, /rest/appliance/recovery/backup/validate, which we could use to programatically validate a backup to make sure the backup is actually working
And of course there is the restore jobs, /rest/appliance/recovery/restore. Might be something to look at if you are testing/validating something in vCenter and want to restore to a “last known good” configuration, but I think if I needed to restore a production vCenter I would go with the UI if it were available.
In this post I have explored the different endpoints available for working with the backup and recovery of the VCSA. They are quite extensive and there are many use cases, not only my specific one for pulling status of runs to a dashboard.
I’ve used the built in API explorer while demonstrating the API. Normally you would use a proper REST client, script or CLI when working against an API. If you just want to explore and want a bit more functionality than what the API explorer can give, you should check out Postman.
Hopefully this post has been valuable for you, reach out if you have any questions or comments.
Thanks for reading!