The ability to perform Policy-based VM-centric backups is a key feature delivered by SimpliVity’s Data Virtualization Platform (DVP). SimpliVity Backup Policies are a collection of rules which automate the protection of virtual machines to meet Recovery Point Objectives (RPO) for data recovery, this includes replicating backups to other SimpliVity Datacenters for off site retention and disaster recovery. SimpliVity Backups allow full virtual machines or individual files/folders to be quickly restored to the point in time when the backup was taken. This post provides a solution using the REST API to schedule SimpliVity backups outside of the standard options available when creating SimpliVity backup policy rules in the vSphere Web Client.
A SimpliVity Backup Policy contains backup rules which answer three questions: 1) frequency of backup, 2) retention period, and 3) in which SimpliVity datacenter to store the backup. A Backup Policy can contain multiple rules to protect VMs at different frequencies, with different retention policies, which can be replicated across multiple Datacenters.
The Edit/Create Backup Rule Dialog allows the backup frequency (how often a VM gets backed up) to be set to Minutes (we support backups as often as every 10 minutes), Hours, or Days.
Each Backup Rule requires a Retention Period and a Destination Datacenter. Backups can be retained for minutes, hours, days, weeks, months, or years. The Destination Datacenter can be the local Datacenter or any other SimpliVity Datacenter within the same Federation.
The Edit/Create Backup Rule dialog also includes Advanced options to configure backup windows. Backups can be configured to be taken on specific days of the week. For example, if you want to backup VMs assigned to the backup policy every Sunday, you would configure the Backup Rule frequency to 1 Day, and set the day of week by selecting Monday in the Advanced options.
There is also an Advanced option which can be used to specify specific calendar days of the month. For example a rule can be created to backup a VM on the 1st of the month and on the last day of the month.
Currently there is no option for creating a rule which will take an annual backup, take a backup only during a specific month, or take a backup on a specific day, for example the first Friday, of a month. To accomplish this, we can use a PowerShell script, the SimpliVity REST API, and the Windows Tasks Scheduler to take backups of virtual machines running on the SimpliVity Data Virtualization Platform (DVP).
The Windows Task Scheduler can be used to execute SVT-BackupVM.ps1 to take an annual SimpliVity backup of a single VM. For example a Trigger can be configured for the Last Friday of January.
An action is also configured to execute the PowerShell script. Here is a nice write up on using Windows Task Scheduler to Run a PowerShell Script.
An additional PowerShell script, SVT-Backup-Script.ps1, allows you to backup multiple SimpliVity VMs. The script has variables that define the OVC IP Address, Username, Password, destination/target SimpliVity Datacenter, and Retention period.
#Parameters
$ovc = "IPAddressofOVC"
$user = "vCenterUser@domain"
$pass = "vCenterUserPassword"
$datacenter = "SVTDatacenterToStoreBackup"
$retention = "525600" # Retention Period in Minutes ie: 525600 = 1 year
SVT-Backup-Script.ps1 reads the list of VMs to backup from a file. In the script the file is defined as C:\temp\simplivity.csv. This text file simply contains the vCenter Inventory name of each VM to backup (one on each line). SVT-Backup-Script.ps1 reads the contents of the file and then loops through each VM name and calls SVT-BackupVM.ps1 to create a SimpliVity backup of each using the parameters defined.
Using SVT-BackupVM.ps1, SVT-Backup-Script.ps1, and the Windows Task Scheduler provides a simple way to automate SimpliVity backups which are required outside the standard options available in SimpliVity Backup Policy Rules.
One thought on “SimpliVity Custom Backup Scheduling Using the REST API”
Something which tripped me up was the folllowing situation. VM on production datacenter was recovered to DR datacenter. Subsequently the same VM was removed from production and recovered from DR to production. Running the SVT-BackupVM.ps1 script failed with Error 400 which means bad command received by REST server. Digging into the REST logs I discovered I had two entries for the same VM, one in DELETED state and other in ALIVE state. When running SVT-BackupVM.ps1 it was attempting to backup the DELETED state VM and failing.
I amended my copy of the SVT-BackupVM.ps1 script to include &state=ALIVE in the statement:
#Get VM Id of Source VM
$uri = “https://” + $ovc + “/api/virtual_machines?limit=1&show_optional_fields=false&name=” + $vmtobackup
I inserted it as follows: ?limit=1&state=ALIVE&show_optional
This now backups up the ALIVE VM and the error 400 isn’t reported. I am looking now to remove the DELETED reference VM from the OVC but haven’t figured this out yet. Hopefully will help others who may receive this error.
Something which tripped me up was the folllowing situation. VM on production datacenter was recovered to DR datacenter. Subsequently the same VM was removed from production and recovered from DR to production. Running the SVT-BackupVM.ps1 script failed with Error 400 which means bad command received by REST server. Digging into the REST logs I discovered I had two entries for the same VM, one in DELETED state and other in ALIVE state. When running SVT-BackupVM.ps1 it was attempting to backup the DELETED state VM and failing.
I amended my copy of the SVT-BackupVM.ps1 script to include &state=ALIVE in the statement:
#Get VM Id of Source VM
$uri = “https://” + $ovc + “/api/virtual_machines?limit=1&show_optional_fields=false&name=” + $vmtobackup
I inserted it as follows: ?limit=1&state=ALIVE&show_optional
This now backups up the ALIVE VM and the error 400 isn’t reported. I am looking now to remove the DELETED reference VM from the OVC but haven’t figured this out yet. Hopefully will help others who may receive this error.