PlateSpin Protect product review Part 2

In the previous post “PlateSpin Protect product review Part 1”, I went over the process for installing and configuring PlateSpin Protect up to the point of where we can start to add a Workload and begin to test replication. So from the web client Dashboard or Workloads tab then click the “Add Workloads” button.

A wizard will appear and ask for some simple information about the workload that you’d like to add. Supply the “Hostname or IP”, “Workload Type”, and provide the appropriate credentials. Then set the initial replication mode and choose the Target or the container I setup in an earlier stage.


Once it’s done adding the workload, it will show as unprotected. Click the “Unprotected” link and a summary page will appear. From the summary page click the “Configure” button to configure the replication schedule.

This is the area where you’ll really want to get it right. There are 5 separate sections consisting of:

  • Tier Settings
  • Replication Settings
  • Failover Settings
  • Prepare for Failover Settings
  • Test Failover Settings

Each section has it’s own set of configs which are pretty self explanatory once you see it. Settings can be tweaked to your delight, unless what you’d like is Continuous Data Protection (CDP) which is not an option. You can configure the recurrence pattern into the minutes range by first choosing Custom and then by using a decimal in the Hourly field for example “.10” for ten minutes. File and Block based replication options can be configured. Block base will require a reboot as it installs a kernel driver for the operating system. You can choose the replication network to use and whether to use DHCP or Static ip addressing. NOTE: Make sure that this is configured correctly or the replication will fail. There’s also options to choose which volumes to protect and whether to make them Thin Disks or resize for additional space.

Click to enlarge the images.

[nggallery id=1]

Once your done with the configuration of this page click “Save & Prepare”. Then click “Execute” to start the replication schedule.

Now PlateSpin will begin it’s process of creating the failover VM, attaching a customized winpe iso to it, booting up the VM then starting the replication. This can be all seen in vCenter. The VM will be named with the convention of “servername_VM”. The replication goes between the source and destination. The PlateSpin Protect server is only orchestrating and monitoring the process. When the replication is done, the VM is shutdown. Subsequent replications will create snapshots. The number of snapshots will depend on what was set for the “Recovery Points to Keep” option in the Tier Settings.

When the replication schedule is not running you get the options shown above making it easy to change and modify the schedule or cause a failover. There is much more to the product than I can blog about without it getting longer than it already has. Check out the product on your own to see more of what’s to offer. To summarize my findings:

The Good:

  • Easy to install and configure
  • Easy to configure Workload
  • Supports Windows and Linux (Workloads)
  • Supports Virtual and Physical (Workloads)
  • Straight forward user interface (simplicity is sometimes good in crisis mode)

The Bad:

  • Does not officially support vSphere 5 (at the time of this post).
  • No way to group VM’s so that you could just failover the group without selecting individual VM.
  • Has to bootup VM for replication to occur (i was told it should only bootup to the custom winpe image the first time but this is not what I witnessed in reality)
  • No CDP option (this is not that big of a deal though in my opinion since most scenarios have too much latency/distance between the production and failover site)

All in all I’d have to give the product a 4 out of 5 for it’s simplicity, flexibility, and it just worked out of the box with no issues. Now this rating is from using the product to protect only 3 VM for about a week. So this is in no way some hardened stress test of the product with 100’s of VM. Nor did I test physical to virtual replication/failover. In other words, do your own testing relative to your requirements and I am in no way be liable.