PHD Virtual Backup (v 8)

Recently I got an opportunity to play around with Unitrends backup solution, which is still in beta. For those of who are not aware, PHD Virtual is now part of Unitrends. At first I was a bit skeptical because I have seen products being wasted after an acquisition. But in this case I think I am quite happy with the progress the product has made under the new name.

My goal is to share my views on my testing of the product and also try and explain the new architecture. Once you get a hang of it, its really simple and makes a lot of sense. In my initial attempt, I sort of screwed things up but that was mostly because I was being hasty and didn’t bother reading the few simple concepts.

Like in previous version, the one we will discuss here, version 8 revolves around the good ole VBA. However now the VBA does a lot more and has delivered on the promises in the past. For example: my previous complain was lack of single pane of glass to manage multiple VBAs, that’s no longer a problem here. In fact they went a step further and made it possible to manage VBAs that could be deployed in Citrix or even Hyper V environments.


In version 7, the concept of appliance roles was introduced and version 8 continues with this model. Each appliance can be dedicated to a single role or a single appliance can have multiple roles configured. So what are those roles?

Presentation (P) – The Presentation appliance is the appliance running the web-based interface you use to configure and manage your installation. Only one presentation appliance is necessary per installation, across all configured environments (including across all hypervisor types). All management and configuration of PHD Virtual Backup occurs through the Presentation Appliance’s web interface.
Management (M) – Each Environment requires one appliance designated as the Management Appliance. This appliance performs inventory and other hypervisor-specific tasks and manages the work of the Engine appliances. Each environment you add to your PHDVB deployment requires the IP address of one appliance to act as Management appliance. The Presentation Appliance can also be designated as a Management Appliance.


Engine (E) – Engine appliances perform the actual data processing and send data to their configured data stores. Engine is the most common role an appliance will take on in your deployment. Appliances with the Presentation and Management role can also be configured with the Engine appliance.


Note: As a general recommendation, you will need at least one Engine appliance for every 10 TB of source data you will protect (or every 1 TB of data if using XenServer or 5 TB is using CIFS backup storage).


So for any deployment you will need at least one VBA that has the P M and E roles. If the environment is small enough, a single VBA can host all those roles. And then add more engines as the environment grows. You can tell someone was thinking scaling. The latest version of the beta also incorporates a tutorial video that gives you a high level view of what the VBA roles may look like when laid down. This will also assist you in determining what will be ideal for your environment. I highly recommend you watch this before moving forward with the full configuration.


I am stealing a diagram from Unitrends documentation to explain how the roles can be laid out.

Deployment single hypervisor

In the example above, as you can tell three VBAs are deployed. It’s a very small two host environment but it maybe a good idea to isolate the engine for the P and M roles if expansions are anticipated down the road. Technically you could with a single engine unless you needed different kinds of backup datastores to backup the data. Yes the engine does NFS, CIFS and attached storage, however you can only have one type of storage per engine. So in the example above, you could assume maybe VBA2 uses NFS and VBA3 uses attached storage. Its also possible that the hosts are running really large VMs that exceed the 10TB limit per engine and that’s why two VBA are deployed.
What could be another reason for two VBAs in the example above? Is it possible that host1 is running esxi and host2 is running Hyper-V? I would say YES its possible to manage two different environments using the same portal but there is one important piece that we are missing, the engine. Take a look at the diagram below:

Deployment multi hypervisor

The diagram above is identical to the one before it with one key difference. Host 2 also has a manager VBA which means the example above could very well work for environment 1 being vSphere based and environment 2 being Hyper V or even Citrix based. Isn’t that awesome!?

Your engine is attached to a disk where the backups are stored. When attaching the storage, you can set encryption to be on if helps you sleep better or some compliance has that requirement. You can also set the compression rate of the backup and block size. Below is some useful information to make those assessments.

Backup Compression:
• Use BDS Setting – The default setting, this option will use the compression setting applied to 
the backup data store. The default setting at the backup data store is GZIP.
• Uncompressed – No compression is applied to the backup data. This can be useful (or required) when using storage devices that perform additional compression.
GZIP – This compression method performs the highest compression level resulting in reduced amount of storage space used. The additional compression used by GZIP will impact performance – backup speed and overall backup time.
• LZOP – This method results in less compression than GZIP but in most cases will impact performance much less, resulting in compressed backups faster than the GZIP alternative.
Block Size:
• Use BDS Setting – The default setting, this option will use the block size setting applied to the 
backup data store. The default setting at the backup data store is 1 MB.
• 512 KB, 1 MB, 2 MB, 4 MB – The size of the backup block used to store backup data should not be adjusted in most situations unless instructed to by support. Adjusting the block size can impact backup and restore performance.

My wow moment:

The deployment is really simple. If you can deploy an OVF you are gold as long as you understand the architecture. Because I didn’t in the beginning I managed to screw up my initial deployment. The folks over at Unitrends were kind enough to get on a call with me to take a look at my issues. On first glance I was informed that I need to update my appliances just like any good ole vendor would suggest. My eyes started to roll until I found out how simple that really is.




The folks over at Unitrends sent me a link to a file which took a few seconds, I unzipped it went to the config tab of the portal on my VBA, hit upload, selected the file with the .phd extension and hot save. And that was it. So I figured if I only have to do that to each VBA it shouldn’t be too bad. But I was informed, because I did it from the presentation VBA that knows the managers and the engines in my environment, all the appliances will be updated and I will get a message once that completes. Sure enough 10 mins later I got the message and as I hit OK, all the branding had changed from PHD to Unitrends and all my appliances were updated. Way better than my original plan of redeploying with the latest appliance. I know this doesn’t highlight the tools backup abilities, but I think the tool itself has proven it can do backups and more over the years. But to me the manageability of your backup solution is key.

One key thing to note is there is also an auto update feature that will pretty much negate the need for you to update the appliance at all as it will happen on its own.

The portal and UI:

When you login to the portal you get a holistic view of your entire environment. This includes number of VMs, number of VMs that have been protected with backups, recent restores, jobs, alerts, available storage etc all in one place. Don’t forget you could be pulling this information from your entire environment that could be hypervisor agnostic. I think this dashboard brings good value to the table and gives a good high level on things. You can hit the cog on the right to change the frequency of how often this data is updated, the default is 5sec.

Portal UI


The errors and some alerts are really my doing. I didn’t realize it was a bad idea to try and backup 400gb of data on a 40gb backup volume. But I was quickly able to add more storage and get past that.

The rest of the tabs are pretty self-explanatory. The protect tab allows you backup, replicate VMs, the Recover tab exactly what it says. You can do full restores or even File level restores. One of the things I like is the ability to change he mac on the VM when doing a full restore, its good to see features from the past are still baked in. The Jobs tab lets you create new jobs, monitor them and view recent jobs.




I really like the report tabs because it presents all the useful information you can think of right out of the box in a very pretty way. Way prettier than I can ever make it because I just don’t have that kind of patience or talent. There are reports around VMs, virtual appliances (this tells you the version your VBAs are running), replication, archives and storage. So there should be all kinds of reports for you to pass around in meetings not just with pretty colors but also very useful information.

The Configure tab is where all the magic happens. This is where you add the multiple VBAs and assign them the appropriate roles. This is also where you can do the update all my VBA magic with a single click. Your SMTP info for email alerting and also the credentials for FLR are stored here.

Lastly another thing that’s covered in this tab brings me to my next topic.


The solution gets installed with a trial license at first. And once you realize you kinda like this, they want money. Urgghh those evil people. Jokes aside, this is also a key factor for a lot of organization on how much will it cost. I don’t have the pricing information at this time. However I do know the product is licensed on a per socket basis. Meaning the sockets of the hosts. So if you have 10 hosts with 4 sockets each that you need to protect all the VMs on you will need 10*4 = 40 licenses. Hopefully the cost will be acceptable like in the past.


Overall I really like the solution. I didn’t cover a lot of the actual backup technology used in the back because most of that has been covered by others and myself in the past. I will post a few links to my previous reviews. I wanted to point out all the new things that I saw and wanted to go over the architecture so that you understand what will it take to deploy this product. If you have half a working brain like myself, all you will need is this post and access to a vCenter where you can deploy the OVF. And you will feel like an all-important backup guru like myself (that’s a joke, I am anything but). Just make sure you watch the tutorial video once you eploy the first VBA, that will really make things extremely simple for you.

The one thing I really like was the way appliances are updated and I think I made that quite clear when I was on the phone with Unitrends. Like everything else there are things that one can desire. Though this is kinda hard to come up with at this point, but I think instead of deploying the VBAs from vCenter, it would be really nice if only the first deployment is needed from vCenter and the rest could be handled from within the solutions portal. Perhaps there could be a report that suggests adding more engines etc to improve performance maybe. The data is already there it seems like, just need to tie it all together. In the end, good job PHD virtual you have done great. And Unitrends don’t let us down because we are spoiled.

Previous reviews:
CloudHook will hook you up – PHD Virtual 6.2

How reliable is your DR plan?

One Response

Leave a Reply