PHD Virtual Backup review and trial – Sponsored
I don’t work with backup products on a daily basis anymore, so I was interested when offered the chance to test and review the PHD virtual backup product. This post is not intended to convince or sell you anything, but to offer you a clear view of what features the product offers and an idea of how you might work with them.
After working with the product for a few weeks, I’ve listed some of the features that were important to me. Overall I thought the product was very easy to setup and work with on a daily basis.
- Built in replication
- Live VM recovery
- Easy setup and job scheduling
The installation of PHD Virtual Backup was a pretty simple process. The Virtual Backup Appliance (VBA) is deployed from an OVF file. In my testing I only deployed a single VBA, but in larger environments multiple VBA’s could be deployed to accommodate backup requirements. The main thing to consider is the VBA must be able to access the storage for the VM it will be backing up. Examples below.
- Local Storage – If you are backing up a VM that is on a datastore that is on local host storage you must deploy a VBA on that host.
- Shared Storage – A common example would be you have multiple clusters, each host within each cluster can see all the same datastores. In this scenario you could deploy a single VBA to each cluster because it would be able to access all of the shared storage within the cluster its deployed to.
The VBA can store your backed up virtual machines on different types of storage. You can use attached virtual disks (VMDK) on the VBA that can reside on any type of shared or local storage, this is the recommended method. Network storage can also be leveraged, the VBA can write backups to CIFS or NFS based storage.
The client to access PHD Backup can be installed on a computer with the vSphere client installed or not. If you do not have the vSphere client you can launch the PHD backup client and still mange backups. If you have the vSphere client installed you will be able to access PHD backups by right clicking on almost an object.
When opening up the console for PHD virtual backup you will first see a dashboard like the one shown below. This gives you a snapshot view of your backup environment. You can see all of your VBA appliances and their stats like available space. There are also some graphs that show storage details and deduplication information. A summary of any Instant VM Recoveries and lastly a list of any alerts or system messages.
To view running jobs and completed jobs you can navigate to the Jobs option on the right menu tree. In the image below I was having a look at the job history, you can see that I had one completed job. You can look at statistics and details about each job to get more details. The current tab on the jobs menu will show you all running jobs and their status.
How to backup a VM:
You can start a manual backup a couple of different ways. The first is to right click on any VM, navigate to the PHD virtual backup menu and choose backup as shown in the image below. You can also start a manual backup from the PHD Backup Console by going to the backup menu and choosing a VM from the inventory tree.
By either selecting the VM or choosing a VM from the management console you will end up with a screen like the one shown below. It lists out your inventory much like the hosts and clusters view in vCenter. For this example I have selected my vMA appliance as shown below.
Next up you will be prompted to choose which VBA appliance you will use for the backup. You will see a summary of IP, Host and available storage details. In my simple lab scenario I am only using one appliance, so there was nothing to choose.
The next step is to choose which type of backup you would like to run, a Virtual Full or Full/Incremental type backup. For this example I am running a Virtual Full backup.
On the next screen you will be prompted to run your backup now or schedule it. I will cover the process for creating a scheduled job later in this post.
Now its time to name the backup job and choose if you want to run any type of verification. There are also options to backup powered off VMs, mark backup as an archive and whether you are using Changed Block Tracking (CBT).
There are a couple of special processing options that you can utilize for backups. These would be used for application related backup requirements. You can Quiesce an application for consistent backups and also run custom scripts before or after the backup.
Last up is a summary page that confirms your selections.
How to restore a VM:
Now I wanted to show how you would go about restoring a VM from backups. There are at least two ways that you can start a restore or recovery. The first would be to right click the VM that you want to restore and choose the recovery option, it will then lead you to a screen like the one shown below. The second option would be to enter the PHD backup console and look at the backup catalog, it would show you a view of all the VMs that you have backed up with the catalog of backups for each. You can then choose the VM and which backup you would like to restore.
While looking at the catalog you can use the fields at the bottom of the screen to search for a VM by name if you have a large environment or narrow the display down by using a date range.
Once you have selected which VM and the backup you will be restoring you are moved along to the next steps. You can see from the image below that you can now apply a name for the Job, choose what type of recovery you will be doing. Some of the nice features that I pointed out in the image below are the ability to add a string to the VM name being recovered. You will also be able to select which datastore you will recover the VM onto and which network or portgroup you will attach it to. And lastly you can choose whether you want the network to be connected at power up.
This features can be beneficial for a number of reasons, one simple one that came to mind was doing a test restore to validate your backup process is working. This would allow you to recover the VM with a unique name and not attach it to the network. Thus allowing you to validate your procedures but not impact your production VMs.
Once you have setup all the Job options you are moved along to the summary screen before starting your recovery.
How to setup a scheduled Job:
If you refer back to the section earlier that I showed how to create a backup, you have the option to run the backup immediately or schedule it. In this section I will just show how you can use the scheduling features to create reoccurring backups.
In the screen below I am showing the option for scheduling daily backups. You can select the start date and time as well as the recurrence interval. For my example below I am setting up a daily backup that will run every day.
The other option is to schedule a weekly type backup. You can choose to run it on specific days of the week and choose how often you want it to reoccur.
Replication is baked into the product and is pretty simple to setup. The approach that PHD takes for replication is one VBA operates as the replication engine and the target is a NFS or CIFS share. With these options you could replicate your backups within the same data center or to another remote site. If you are going to replicate the backups to another site the most likely choice is a remote NFS or CIFS location. The VBA is really replicating a powered down standby VM to the remote location rather than backup data. The replication traffic is network based and can traverse sites.
The setup of PHD backup replication is a very straightforward process. A big plus is that if you already own the backup product you can now get replication setup without having to invest in a specific replication product if this meets your needs. With vSphere replication being offered for free with new vSphere 5.1 Enterprise licensing thats always an option also, but I like the fact that its one less product to setup and manage by using PHD’s replication. And you can manage your backup and replication in one product.
Instant VM recovery:
This type of feature is available in products from multiple vendors now but is still an exciting feature. The idea is that you need access to a backed up copy of a virtual machine and cannot wait for a restore to complete. With an Instant VM recovery you are actually powering on the backed up copy of the VM. This happens in a very short time frame. You might need to do this for a couple of reasons, one would be just for backup testing. The other would be for a real world issue.
By default the VM is brought online sitting on the volume that holds the backed up versions, you will want to move this to one of your production datastores for performance and management reasons. You could do this with a storage vMotion or PHD has included an option to seed the VM over to another datastore as a second option.
A short video that show whats upcoming in versions 6.1 of PHD Backup
There are some other features that I did not have time to fully test that are built into the product like file level recovery, Exchange log truncation, PHD exporter and encryption. These are very powerful features that may be applicable to your environment. I know the file level restores are a very popular feature that most customers will request.
About Brian Suhr
Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design