Modern storage appliances offer the capabilities to manage volume snapshots. Such snapshots can be used for multiple purposes including the option to replicate these to a secondary array for disaster recovery and availability scenarios. The HPE StoreVirtual VSA makes no exception. This article explores the options to setup HPE StoreVirtual Backup from storage snapshot using Veeam.
What are the benefits of running VM backups from a Storage Snapshot?
In the case of VMware when taking a backup of a virtual machine the vSphere takes an “hypervisor snapshot”. Essentially it freezes (quiesce) access to the base vmdk file and creates a new one where the changes are written (VM is still running). At this point the backup application can copy the base vmdk file and when completed acknowledges the hypervisor the backup is completed. At this point the hypervisor is ready to merge the delta information back into the base file. Once this operation is completed the delta file with changes is deleted. The Veeam backup from storage snapshot leverages the same framework and automates one more step by letting the storage controller (HPE StoreVirtual in this case) to create a storage snapshot of the volume as soon as the hypervisor snapshot is created. In this scenario the following occurs:
- Veeam triggers the backup for a VM
- Veeam leverages VSS or VMware tools to quiesce applications or file system inside VM
- VMware vSphere creates hypervisor snapshot
- Veeam triggers a storage snapshot of the volume where the VM is sitting
- The storage snapshot now includes the base file plus the delta file
- Veeam instructs VMware vSphere the backup is “completed”
- VMware vSphere hypervisor merges the changes from the delta file to the base vmdk disk
- Veeam now takes a backup of the base vmdk file from the storage snapshot and deletes the storage snapshot when complete
The main advantage of this approach is the time for the creation of the storage snapshot is very short. This means the delta file will never grow massively making it easy for the hypervisor to merge the changes back to the base vmdk file. This is very important especially for virtual machines with highly transactional applications like databases. To quiesce a VM (or stun a VM) it only takes milliseconds and gives the hypervisor the opportunity to “close or seal” the base vmdk file and redirect the changes to the new delta vmdk file. When this process is followed by a storage snapshot it is the best of the two worlds: very small changes to consolidate back to the base vmdk file and the ability to backup the base vmdk file from a different location (storage snapshot) that can also sit on different physical disk. This greatly reduces the impact on production storage during the virtual machine backup operations.
Veeam Backup server natively integrates with various vendors for primary and secondary storage types. The HPE StoreVirtual is one of them. This article explores the main configuration steps on how to setup Veeam for HPE StoreVirtual Backup from storage snapshot.
Setup Veeam for HPE StoreVirtual Backup from Storage Snapshot
In order for Veeam to leverage the HPE StoreVirtual Backup from a Storage Snapshot the “path” to storage volume where the VMs are sitting needs to be visible to the Veeam Backup Proxy running the backup job. In particular the Veeam Backup Proxy can use different Transport Modes to access in read/write the content on the storage volumes. In this case the mode required is the “Direct SAN Access Mode”. This method can be used when the volume is presented as block storage like iSCSI and FC protocols to the Veeam Backup Proxy.
First step is to login to the HPE Central Management Console (CMC) to configure the access for the volumes.
From the HPE CMC let’s choose the intended Management Group where the volume resides.
HPE CMC will require to login with an Admin user for the Management Group. Next step is to retrieve the iSCSI initiator name from the Veeam Backup Proxy.
In the machine running as Veeam Backup Proxy let’s start the Microsoft iSCSI initiator if not yet running. In the Administrative Tools from Windows Control panel there is a link to the iSCSI utility. In the configuration there is the name of the iSCSI initiator that will be used to configure access to HPE StoreVirtual volume.
As already covered in previous articles dedicated to HPE StoreVirtual platform it is now time to create a “New Server” for the intended StoreVirtual volume. Name and description are free text. The controlling Server IP address works with both IP and Hostname. So FQDN name resolution is key also in this case. In the “Allow access via iSCSI” the option to provide the Initiator Node Name. In this case the Veeam Backup Proxy. The rest of the options can be left as default unless security is required through a Challenging Authentication Protocol which has to be configured on the iSCSI Initiator side as well.
Next step is to configure the Veeam Backup Proxy. From the properties the Transport Mode should be either Automatic or Direct Storage Access. With the connected datastores the default option is for this Veeam Backup Proxy to see everything or just the intended ones.
The automatic selection will dynamically use the best method available with Direct Storage Access first. There is also the option to automatically failover to Network Mode should the other methods not be available. This option works great with 10 Gb Ethernet Networks and faster. Management interfaces using “standard” 1Gb network should be avoided as provide low throughput for backup purposes.
At this point everything is ready to create an HPE StoreVirtual Backup from Storage Snapshot using Veeam.
From the object it is possible to select the entire volume.
In the Storage section of the wizard let’s make sure the configured Veeam Backup Proxy is selected.
From the Advanced > vSphere tab the Enable VMware Tools quiescence should be enabled for VMs that do not leverage VSS or have other methods to “freeze” applications and flush all dirty blocks from RAM Memory to disk. This is the example for a simple Linux machine (as per this article). In such case the backup will be file and crash consistent.
In the Integration tab it is possible to enable the backup from storage snapshot option. In addition, the ability to limit the number of VMs to process and also failover to a standard backup mode.
Finally, in the Scripts tab the option to run custom scripts for example to quiesce applications and make the backup application consistent also for solutions that do natively provide VSS approach. For example MySQL, PostgreSQL, Domino and others. Will cover these and more with dedicated articles.
In the Guest Processing it is possible to enable the Application-aware option. For this article there is only a single Linux VM which does not require this option.
The same volume can host other VMs like SQL, Oracle, SharePoint and more for which there is the ability to set predefined settings. All covered in dedicated articles. So might be a good idea to leave the option enabled for other VMs on the same volume.
The application-aware requires a user account that will be used to test the interaction. In this case only a single account is used to verify a single VM. Of course when multiple VMs are located on the same volume it is possible to specify a Master account and a specific one per VM.
The verification test for the account completed successfully.
Next is to configure a schedule as required. It can be paired also with a volume snapshot schedule operated by the HPE StoreVirtual appliance itself. This provides great flexibility for multiple scenarios.
And a quick summary with the main details before committing the changes. Very nicely also the command line to script exactly the same job.
From the job statistics in the general panel there is a list of actions with status. HPE StoreVirtual created a storage snapshot in a second (or less)!
When clicking on the single VMs the statistics shows the actions for single VMs. In this case the hypervisor snapshot creation and deletion.
From the same log also the HPE StoreVirtual Backup from Storage Snapshot.
Add Comment