The two key features for AssureStor are hypervisor based replication and the automation for failover, testing and failback.
As a cloud service provider we are always looking at how we can reduce risk for our customers, the ability to provide a DR service that delivers RPO’s typically as low as 15 seconds, over relatively slow connections is fantastic. And as the replication is performed at the hypervisor level we can protect any virtual (VMware or Hyper-V) environment without worry about the storage layer. The automation element is also a crucial element as it ensures we do not have to spend lots of man hours in the event of a DR failover request, as well as streamlining the ability to test the DR environment without needing any down-time of the production environment. And finally add in the ability to automatically reverse replication once you have failed over allowing you to re-seed the production site and failback with minimal downtime and you have a great all-round DR solution.
How has it helped my organization?
Before we took on Zerto our DRaaS offering was based on snapshot based backup’s with an automated restore process to our cloud hypervisors. This was a good service but we could only offer RPO’s as low as 1 hour and even then this was subject to caveats specifically around the size of the VM and how quickly we could ship the new data to our cloud platform. In addition, testing was much more cumbersome and meant a much higher number of hours had to be invested in every DR test, ultimately raising our costs. With Zerto in place we are now offering commercially sound services to small and large businesses without the worry of needing to invest in large numbers of staff to manage and perform testing, etc.
What needs improvement?
Backup capability as it is limited and not as streamlined as it could be. At present Zerto delivers backup protection by making duplicate copies of VM disks to a defined storage location (but this is limited on the schedule and retention). In the latest version 4.5 this has now been extended with the capability to do object level recovery from the replicated VMs, the caveat here is that the retention period is limited to the journal retention (which is a maximum of 14 days). I would like to see a more integrated backup/retention capability in the solution allowing more flexible scheduling and unlimited retention with the capability to easily restore objects using the one Zerto web interface. The backup images should be able to be stored off-site, away from the main replication site, and easily be reintegrated in the main DR platform if needed for VM recovery of an old image.
For how long have I used the solution?
I've been using it for 18 months. v4.5 for the last four weeks, and prior to that we ran v4.0 since our initial deployment.
What was my experience with deployment of the solution?
When we first deployed Zerto we didn’t understand some of the limitations around the built-in database (it uses SQLite). Whilst this would normally be fine for most small to medium deployments (the database is supported for up to 100 protected VMs and 4 sites), as a cloud provider we needed to have greater scalability. This is provided by using a full deployment of Microsoft SQL, thankfully Zerto have a tool that will migrate the SQLite DB into your Microsoft SQL server so the transfer is pain free, but I would make sure that anyone who is deploying in an environment that may have more than 100 VMs to deploy initially on Microsoft SQL. Another area to be aware of in scalability is not with Zerto itself but the demands it can put on the DR storage environment, you will be replicating all your VM disk writes as well as journaling and potentially adding more demand when testing (as the Zerto continues to replicate even when testing, which is great, but does hammer the storage).
What do I think about the stability of the solution?
We've had no issues with the performance.
What do I think about the scalability of the solution?
It's been able to scale for our needs.
How are customer service and technical support?
In one word, fantastic. When we evaluate a product one of the key areas we look at is the level of technical support we will get from the vendor. Bottom line IT systems have a habit of going wrong (one of the reasons I have had a job for the past 20 years), so once you accept that no system will be error-free, you need to know that if you do need help its available. We have had issues, bugs and questions and in every case we have been supported by the Zerto tech support team.
Which solution did I use previously and why did I switch?
Our DRaaS platform, prior to Zerto, was an extension of our Asigra Cloud Backup platform. Whilst this worked it could not deliver the low RPOs we now see with Zerto nor the efficiencies we see from Zerto in managing day-to-day tasks on the platform such as validation, failover tests (and on the odd occasions actual live failovers). Our choice with Zerto was based on our own piece of mind, we protect a variety of end-users so never failing them (i.e. never failing to replicate their VMs and know we can spin them up when needed) was crucial, Zerto has delivered this for us.
How was the initial setup?
Our deployment was fairly complex, but then we had to deploy a platform capable of multi-tenant support with complex networking and integration with vCloud Director so that customers could access their DR systems via a secure web interface. If you are deploying a site-to-site solution then deployment is very straightforward. Each site requires a Zerto Virtual Manager (ZVM) which is deployed upon Windows, this will then integrate with your vCenter servers at each site. From here it’s a few button clicks to deploy the Virtual Replication Appliance/s (VRAs) which are small Linux systems bound to each host that handle the ‘smart’ features of Zerto Replication, linking the site and your off.
What about the implementation team?
Deployment was performed using in-house resources. The most important bit of advice I can offer to anyone considering implementing Zerto is understand your storage requirements at the production site and then decide on what levels of performance are acceptable. If you want to have low RPOs (seconds) then remember that you will be replicating all of your production writes into the DR storage device. And as initially these writes are put into the journal datastore and then read out after the defined retention period and written to the actual storage datastore be careful not to overload your DR SAN. As an example we deploy using separate SANs for journals and customer storage, with larger customers getting dedicated storage designed to accommodate their traffic patterns.
What's my experience with pricing, setup cost, and licensing?
As a Zerto Cloud Service Provider (CSP) our licence model is different to end-users who can purchase the licence on a perpetual basis. For us the ROI was under 6 months, but we already had a large portion of the hypervisor and storage environment needed so were able to keep our costs to a minimum.
What other advice do I have?
Zerto, in my opinion, is one of the best DR products on the market currently, its only flaw (if it can be called that) is that it is limited to virtual environments, specifically VMware & Hyper-V (it does also support replication to AWS if needed). If you are looking to streamline your DR capability and remove risk then speak to Zerto and get them to run you through a demo, what they say the product can do is not sales talk, it really can do it.
Recovery Checkpoints (Journal)
**Disclosure: My company has a business relationship with this vendor other than being a customer: We're partners.