Integration
Last updated
Last updated
In this section, we're going to highlight key aspects necessary to integrate 3rd party solutions with Storware Backup & Recovery. We assume a typical scenario, where you want to invoke Storware Backup & Recovery operations on behalf of a user of a self-service portal. We assume that the end-user uses the above-mentioned portal for a subset of administrative actions, and we want to give a user ability to perform basic backup-related operations.
These include:
listing VMs in inventory (including already non-existing)
getting VM details
performing backup of a VM on the list
browse backup history
restore specified VM
monitor progress of each operation
manage policies and schedules
The architecture below shows key components, communication, and data flows. All communication between 3rd party systems goes via RESTful API exposed by Storware Backup & Recovery Server. Tasks are being performed by the Node behind the scenes. End-user is going to use only a 3rd party system to invoke and monitor the status of the tasks.
Multi-tenancy and permission handling are on the 3rd-party system side. There is however tenantID field in several cases which can be used to assign objects to the tenant on the 3rd-party system side, later to be used in filter criteria.
A 3rd-party system must use a dedicated Storware Backup & Recovery account to perform operations.
Your system is going to communicate over HTTPS which by default runs on port 8181, but during the setup can optionally be exposed on 443 as well. You need to generate an SSL certificate as described in chapter Enabling HTTPS connectivity for nodes.
Storware Backup & Recovery can invoke operations only on VMs that exist in its inventory. It is being synced periodically so that it reflects changes in the virtualization platform.
REST API can either be invoked directly or use the generated client for Java. Contact us to receive the current client version matching your language.
The base URL for API calls is: https://STORWARE_SERVER:PORT/api. We'll assume that all endpoints are prefixed with the base URL in the rest of this guide. In this guide we'll focus on the integration process, and skip actual requests and responses here and - check API docs for details.
Quite often in requests or responses, Storware Backup & Recovery requires NameAndGuid to refer to other objects. GUID is the ID that you can use later to get additional information about hypervisor or backup. For convenience, we provide name to present it on the list views.
When you need to provide NameAndGuid in requests, you actually need to pass the object that has just GUID provided.
A similar concept applies to enum types - Storware Backup & Recovery uses EnumNameAndDescription with name as enum name and description to show it to the end-user in a more user-friendly way. Anywhere when you are required to use enums such as type, state, days of the week, etc. you need to use EnumNameAndDescription object. In requests, you need to provide just name.
When you want to invoke APIs, you need to be authenticated first. Storware Backup & Recovery API exposes an endpoint that you need to send login and password first to the POST /session/login endpoint. Save cookies so that you'll be able to invoke the next calls.
If you ever call any end-point without having a valid session, you'll receive 401 Unauthorized responses. You need to re-login then and repeat your request.
In the rest of this guide, we assume that you have a valid session before you call any end-point mentioned.
If you have a dedicated view of the VMs that are available for restore you need to call: /virtual-machines. This will retrieve all VMs visible by Storware Backup & Recovery. GUID is the ID that you should refer to when invoking any operation on the VM. UUID is the ID that your infrastructure uses to identify objects.
For a multi-tenant environment make sure to filter out VMs on your side according to your ACLs or ownership of the VMs. For OpenStack Storware Backup & Recovery records project ID and allow to use it to filter VMs like this: /virtual-machines?tenantid={PROJECTID}
You may want to show VM details to the end-user. Call GET /virtual-machines/{guid}. Some useful information includes assigned policies, protection status or last backup sizes, and timestamps.
The Backup consists of 2 phases in Storware Backup & Recovery - export and store. End-user will initiate "backup", but your system should create an "export" task. Store task will be created automatically once export succeeds. To create an export task you need to provide the following information by the POST /tasks/export endpoint:
windowStart and windowEnd - start and end of a time window for an export task - a task will fail if it is not started within this time range; both values provided as UNIX time in milliseconds
priority - 0-100 - higher priority tasks are executed first; 50 by default
backupType - FULL or INCREMENTAL; note that incremental backups are supported only for some platforms and they require at least one schedule of type incremental assigned to the policy that VM uses; if a snapshot for incremental backup is not found, a full backup will be done instead
backupDestination - provided as NameAndGuid - target where the backup is going to be stored
protectedEntities - collection of NameAndGuid referring to VMs that you want to backup - Storware Backup & Recovery will create one export task for each referred VM
In the response, you'll receive task details, and you may want to record GUID to monitor later its progress or status. A new backup entry is going to be created automatically - you may also want to record this number if you want to present its details.
You can show the status and progress of each operation by calling GET /tasks (retrieves all tasks) and filtering the results or monitoring a particular task by calling GET /tasks/{guid}. There are also several useful query parameters that you can use to retrieve a filtered list:
protectedEntity - GUID of VM that you refer to
backup - GUID of a backup
schedule - GUID of a schedule that invoked this task
state - task state as EnumNameAndDescription: QUEUED, RUNNING, FINISHED, FAILED, CANCELLED
type - task type as EnumNameAndDescription: INDEX, EXPORT, STORE, RESTORE, OLD_BACKUPS_REMOVAL, OLD_SNAPSHOTS_REMOVAL, IMPORT, MOUNT, UNMOUNT, DELETE, SNAPSHOT, SNAPSHOT_REVERSION
tenantId - to filter out tasks only belonging to VMs owned by a particular tenantID (currently OpenStack only)
You can retrieve backup history including statuses, sizes, and time stats for each backup by calling GET /backups/?protected-entity={guid}, where you provide guid of your VM.
Similar to backup, restore typically consists of several tasks. If you restore VM to the file system on the node, then it is just one task: restore. However, you usually want the user to restore and import VM automatically to the virtualization platform or mount it for file-level restore.
Let's focus on the restore with import case. You need to submit a task to POST /tasks/restore-and-import endpoint and provide:
backup - GUID of a backup to be restored
hypervisor or hypervisorManager - specify either one or the other - your target HV or HV manager depending on the virtualization platform
restoredPeName - optional name of a restored VM
restoreStorageId - some virtualization platforms require this to select the storage to which VM has to be restored;
restoreClusterId - some virtualization platforms require this to select the cluster to which VM has to be restored;
restoreProject - some virtualization platforms require this to select a project to which VM has to be restored
dataCenter - some virtualization platforms require this to select datacenter to which VM has to be restored; this is a DataCenterDTO (currently having only name property)
Once the restore task completes, an import task will be created. Monitor tasks to show user current progress.
In order to allow users to have an automatic, scheduled backup you need to create a schedule and policy and make sure that both VMs and schedules are assigned to the policy. A Policy can have multiple schedules. VM can have exactly one backup policy assigned. Schedules are not assigned directly to the schedules - they are actually a part of a Policy Rule. And can be assigned to multiple rules, however in an external system this maybe not be convenient and we recommend using dedicated schedules for each policy. Currently, Storware Backup & Recovery supports one rule per policy, but from an API perspective - there is a collection of rules in the policy.
Schedules can be active or not, they have to specify which type of backup needs to be done, and when. Policies specify options to automatically assign VMs based on certain criteria. It is not recommended to expose these criteria to the end-user, as currently multi-tenancy support doesn't cover this case.
When you're exposing schedules and policies you may want to filter only these owned by a particular tenant. When you create/update them you need to provide additional tenantId to be able later to use it when listing objects.
Listing schedules
To list schedules and retrieve basic info use GET /schedules with optional query param tenantid.
Creating schedules
To create a **** schedule use POST /schedules endpoint and provide the following information:
name - has to be globally unique, however, you can handle uniqueness on your site or generate names if you don't need to present them to end-user
backupType - EnumNameAndDescription - a type of backup to perform: FULL or INCREMENTAL
type - EnumNameAndDescription - for VM backup it is VM_BACKUP (other options are APP_BACKUP and SNAPSHOT); this type must match policy type
executionType - EnumNameAndDescription - schedules can be executed at given TIME (based on hour field) or on INTERVAL basis
hour - a time when schedule should be invoked - it is a time offset from UTC midnight in milliseconds, for example 3600 means 1:00 am UTC
active - a boolean flag to activate or deactivate the schedule
startWindowLength - used to assign window end to export tasks in milliseconds (which will be set to hour + startWindowLength)
daysOfWeek - collection of EnumNameAndDescription - days of the week MONDAY, ..., SUNDAY when schedule needs to be run
months - collection of EnumNameAndDescription - days of the week JANUARY, ..., DECEMBER when schedule needs to be run; if empty - only during specified months schedule is executed
dayOfWeekOccurrences - collection of EnumNameAndDescription - days of the week occurrences FIRST_IN_MONTH, SECOND_IN_MONTH, THIRD_IN_MONTH, FOURTH_IN_MONTH, LAST_IN_MONTH, when schedule needs to be run; if empty - only during first, ..., the last occurrence of specified days of week schedule is executed
rules - collection of NameAndGuid - policy rules to which assign schedule to
interval - object containing startHour, endHour (time offset from UTC midnight in milliseconds) and frequency (also in milliseconds)
tenantId - string identifying tenant to which assign the schedule - this is used only by 3rd party system to filter out the listing
Getting schedule details
To get schedule details use GET /schedules/{guid}.
Updating schedule
To update the schedule use PUT /schedules/{guid} endpoint and provide the same information as in the creation request.
Deleting schedule
To delete the schedule use DELETE /schedules/{guid}.
Listing VM backup policies
To list policies and retrieve basic info use GET /policies/vm-backup with optional query param tenantid.
Creating VM backup policy
Policy creation is a 2 step process. It requires creating policy itself and then setting rules set on the policy. This ruleset currently must be a 1 element set.
To create a schedule use POST /policies/vm-backup endpoint and provide the following information:
name - has to be globally unique, however, you can handle uniqueness on your site or generate names if you don't need to present them to end-user* priority - priority assigned to backup tasks (0-100)
autoRemoveNonPresent - a boolean flag to automatically remove from policy non-existing VMs
autoAssignSettings - object specifying details for VM auto-assignment mechanism - not supported in the multi-tenant environment; you need to set mode variable of this object to DISABLED
vms - collection of NameAndGuid containing GUIDs of VMs to be assigned to the policy
tenantId - string identifying tenant to which assign the policy - this is used only by 3rd party system to filter out the listing
You'll receive details including GUID of a newly created policy. The second step is to create a rule and assign it to the policy. Use POST /rules/vm-backup with the following information:
name - we recommend generating it if not used by the user
schedules - collection of NameAndGuid you want to be assigned to this policy
policy - NameAndGuid of a policy that you want this rule to be assigned to.
Getting VM backup policy details
To get policy details use GET /policies/vm-backup/{guid}.
Updating VM backup policy
To update policy use PUT /policies/vm-backup/{guid} endpoint and provide the same information as in the creation request. Keep in mind, that you may need to update rules as well. You can either use DELETE /rules/vm-backup/{guid} and later POST /rules/vm-backup and re-create the policy rule or use PUT /rules/vm-backup/{guid} to update specific settings of a specific rule. GUID of a rule can be found in policy details (rules field).
Deleting VM backup policy
To delete policy use DELETE /policies/vm-backup/{guid}. Policy rules will be removed automatically.
