VMware Live Recovery Reviews

We use SRM to replicate our important servers to our VR site. We are customers of VMware and I'm a junior manager. 

The replication part of SRM is really good. We once had our production site collapse completely and we were able to recover all the data. The restore level of the application is very good. 

The solution is on the expensive side. 

I've been using this solution for four years. 

We've found the solution to be stable. 

The solution is scalable. 

We used the documentation for our initial setup and had some difficulties. The deployment was carried out in-house and took a day or two. We had some help from colleagues in other companies and had a couple of people from our company involved in the deployment. 

We initially took out a five-year contract and recently extended it for another 12 months. It's quite an expensive solution. 

I think this is a good tool that's easy to manage and worth the cost, so I rate it nine out of 10. 

In terms of recovery, if you have a test job script, you can put it on top of it. You can create custom steps so that it will be more granular. It will be an easy, one click solution when it comes to the recovery application.

It would be good if this solution could integrate configuration management software such as Chef Infra.

I've been using VMware SRM for more than a year.

The stability is always good because we replicate daily. I have never seen any issues because the replication is always 100% successful.

You can add multiple appliances, and it supports enterprise environments.

Technical support is very good.

The initial setup is straightforward.

The deployment takes about three hours.

VMware SRM is the best sustainability solution, I would rate it at nine on a scale from one to ten.

We use it for disaster recovery.

I like how VMware SRM is able to automate and orchestrate disaster recovery.

The price, in general, could be lower.

I've been using this solution for probably three years now.

It is a stable solution.

It is scalable.

My experience with technical support has been fine.

The installation is straightforward if you have the required skill level. It took about a week for the initial setup.

The price could be lower, in general. My clients pay for an annual license.

I recommend VMware SRM and rate it at eight on a scale from one to ten.

We use SRM for our failover strategy. It is for disaster recovery on failover.

Our systems fail over using SRM. So, we do a big bang DR, which is biannual, and we fail over our fairly massive Epic electronic health record (EHR) and our core applications. It takes us about 30 minutes to fail over using SRM, which is pretty good. In most hospitals that have Epic installed, Epic does the audit to make sure that we can fail over if something were to happen. Normally, sites will have a DR solution specific to the EHR, but right now, our pain point is the third-party tier-one clinical applications.

We've had configuration issues on occasion. We start to fail over, and then we have to call it off because the configuration is not right, or the data stores aren't configured correctly in the secondary data center. Oftentimes, it is just the experience level of the team, and we have to bring in the vendor to help and validate our configuration.

I have been using this solution for probably five years.

Their support is excellent.

I would rate it an eight out of 10. There is some complexity there, and that's where I would bring it down from a 10.

I use VMware SRM for DR testing and VR.

The solution is simple to use and has effective automation.

VMware SRM does not have the capacity to do DR tests. We had issues whenever we were doing tests with the root cause analysis. We had 70 to 80 percent successful results because the vCenters were overloaded and that was the reason that we were having capacity issues.

We have been experiencing an additional problem when adding a regular VM in the replicated storage. By default, it will show an error. However, there is not any monitoring mechanism that would show you are not supposed to have a regular VM which is non-VR in the replicated SRM storage. Whenever we used to do testing we had to figure out that a regular VM is there and remove it manually.

I have been using this solution for approximately seven years.

The stability should be smooth, and as for the capacity, we should be able to run the test successfully. However, from our research and DR test results, we came to the conclusion that we have to run the DR test during the non-production hours. Logically, they should be able to be done during the production hours, but that is not the case. We have to ensure that the vCenters are free and are not doing regular work for us not to have any issues during the DR test.

There needs to be better stability during heavy capacity in future releases.

The solution is easy to scale.

The solution is used extensively in our large organization.

When we first started out using this solution we encountered a few issues and used the support but we now know how to fix most of the issues and have not used them. Additionally, we have our own team for support.

The installation is logically simple and in the medium range of difficulty. However, you need to make sure you have the proper infrastructure.

I have evaluated Veritas and Zerto.

I would advise others looking into implementing VMware SRM not to totally be dependent upon it. Review other solutions, such as Veritas regulatory platform and Zerto. There are newer VM DR options coming out regularly and they should not have only one solution.

I rate VMware SRM a six out of ten.

We are consultants in disaster recovery software. We implement VMware products for our clients.

It is easy to implement for my clients. 

It's a very nice product.

I would like to see this solution be more scalable.

We currently use our security in addition to VMware SRM.

I am certified in VMware and VCloud. 

I have been using VMware SRM for ten years.

We have no issues with the stability of VMware SRM.

VMware SRM is scalable, but it can be improved.

We have 15 to 20 customers who are using SRM. We have customers not only in the US but in the UK also.

They provide very good technical support that is affordable.

We are also using Zerto.

It is very easy when it comes to integrating with a data center or an appliance, but it's a bit complicated.

The length of time it takes to deploy depends on the database we are accessing. It can take two hours to deploy.

We have two senior persons to deploy and maintain it.

I am not involved with the pricing. 

We have a procurement team and sales team that work with the vendors.

I would definitely recommend this solution to others who are interested in using it.

I would rate VMware SRM an eight out of ten.

VMware SRM is used for our disaster recovery site, which is an on-premises colo (Colocation) facility. The general use case is for disaster recovery for three of our applications those being imaging, payroll, and real estate.  

I would say SRM's ability to recover my virtual machines in a timely manner and to perform bi-annual testing are the two things it has provided that are really valuable.  

I would say VMware has room for improvement with this product. I am sure it is probably better in their 7.0 version, but there are still some bugs in the 6.O version that relates to using it with different browsers. I think a lot of what I run into is related to the 6.0 version. I believe a lot of those bugs have been fixed in the UI once you upgrade to 7.0.  

We have been using the VMware SRM solution for about six years.  

The stability of SRM has been excellent. I would give it a nine-out-of-ten. It is a pretty solid solution.  

I believe it would probably scale just fine. I only protect 25 VMs based on our licensing and I do it that way even though I actually have about 200 virtual servers. I can not really say I have done a lot to test scalability. In the six years that I have been dealing with SRM, I have just been protecting those 25 VMs. I do not have hands-on experience as to how well it would scale out.  

I have dealt with the technical support at times in the last year. I would give VMware's tech support a nine-out-of-ten. They are responsive and get you a useful reply.  

Disaster recovery was completely done with physical servers prior to when we started using VMware. When we went to VMware, we started using SRM. So the first time we went with the virtual environment we deployed SRM. We just went straight with SRM just because it is a VMware product. It was already well-integrated and did what we needed it to do.  

The installation and initial setup were pretty straightforward. The deployment, overall, was pretty straightforward. There was a little implementation structure we had to factor in related to my storage array. But besides that, it was pretty straightforward and easy enough all the way around.  

I pay for SRM per year. It is about $3,000 a year for the 25 pack. The package gives you the ability to protect up to 25 virtual machines.  

From what I have seen, a lot of these new hyper-converged systems come with certain components that do a lot of what SRM does. My opinion and advice to people considering SRM would be to look to your hardware vendor or consultant. They may have some replication pieces in there that allow you to possibly not use SRM or go ahead and stay with what you already have. Depending on your situation, different combinations might prove more beneficial either within the architecture or by cost-benefit. There are a lot of options out there now for disc replication and bringing machines up at other locations.  

On a scale from one to ten (where one is the worst and ten is the best), I would rate the SRM as about an eight-out-of-ten.  

We are in technology and services but we also do enterprise architecture and strategic planning. We always work on the customer side, but we work very closely together with key partners and key vendors in the industry. This includes VMware, but other vendors as well. We realize solutions on the customer's behalf and we are also always solution-oriented and committed to delivering what the client needs. That is why we work intensively and closely with vendors like VMware.  

With VMware SRM, we had a technical account manager before coming on with them and level three support all on standby just in case we were to encounter issues. We just happened to encounter a lot of issues.  

We integrated the product at the same time partly because of discovery and partly because we want to stay vendor agnostic. We work with whatever the client has if it is a viable product. One might be using Hyper-V and another one might be using KVM (Kernel-based Virtual Machine) or Xen Project or AHV (Acropolis HyperVisor). We treat them equally to do what they need and also work with other parties, like Red Hat or Nutanix or whatever other solutions are necessary. Of course, we take our experiences from every client and every project with us on to the next opportunity.  

What I like the most about SRM is the delta sync. We typically approach a project from an architecture perspective and we do service grouping. For example, take a situation where we plan to do a migration. We decide to go with a setup where there is a front-end portal server, there are duplication servers and there is one back-end database server. This means there are four separate VMs each representing one particular service. To get the services across, we have to wait until we have the full image replication complete. By the time we kick it off, the replication has already begun to trickle in. You can parameterize a little bit. When you really want to do the migration — probably during a service outage on the weekends as it is for production — the majority of the data is already migrated to the other side. That helps a lot because you do not need to have a tremendous service outage with this model compared to doing it in a more traditional way.  

Of course, VMware SRM not the only solution that is capable of doing this anymore. But if you have a heterogeneous environment — environments are not equal on both sides — this solution can be an advantage. In our situation, we had completely different technical specs and technology foundations at the source and target. In this case, the product is really is an enabler on the condition that you have the same hypervisor on the other side.  

I would say a lot could be changed to improve the product in terms of troubleshooting and supportability. I think about every two weeks, we had an incident somewhere in the software stack. There were problems that we faced with the vRA (vRealize Automation) multiple times. We had to fix the problem and redeploy it more than once to get it to work properly. Then we had to completely redo our replication. That is a big drawback because it means we had to cancel other plans that had already been scheduled.  

To summarize it briefly: users need a lot of enhancement to the quality and functionality of the software for it to be very useful.  

For support of VMware version 3, a more recent patch needs to be released. There were a few times that fixes were released but we have already upgraded to those latest levels and the known compatibility problems are not fixed.  

The replication advantage the product has does not work for all VMs. For example, if you have a large difference in change frequency within a VM and the VM is big — in one case our VM was 42 terabytes — the data just does not get across in the migration. So the product is really not able to handle either very big VMs or a very large change frequency. I remember we tried it with one Data Mart SQL database where we do continuous ETLs (Extract, Transform and Load). The data reloads on a daily basis. The replication takes too long to complete. The next afternoon after the migration started, we were more or less at 50%. By the evening, we were at 70%. We scratched the data reloaded and started all over again. We found no means to accelerate that. By the time you appear to be progressing, you have to redo the migration. So that is another disadvantage when trying to use SRM.  

There are a lot of minor things that need to be in place on both sides of the migration to make it work. If something goes wrong in the middle of the migration, you will have a tough time trying to troubleshoot it. The product has an insufficient method of logging, an insufficient level of operability, and an insufficient level of detailed technical tracing. This lack of information makes it so you can not immediately pinpoint the issues to troubleshoot them. It cost us multiple weekends of lost time while trying to troubleshoot because we do not get this information from the product.  

But the things I would like to see for sure in a new release are:  

• Fix all minor connectivity issues with auto-recovery.  
• Auto-diagnose, auto-identify, and auto-correct issues as they occur and at least try to fix the issues a few times before allowing it to fail. If the fix is not successful then at least inform users that the fix attempt was made and the particular area where the issue is suspected so that users do not lose hours to troubleshooting.  
  
• Open up the solution to be more environmentally agnostic. It should not be so strongly integrated with vCenter. It should be loosely coupled with vCenter and allow other solutions.  
• Make the product more robust and much faster. Many replications we have initiated took two weeks before going to the switchover. A lot happens in two weeks. It seems like an eternity when you have no idea why replications stalled over that long of a period of time.  
  

I was using this between 2018 and 2019. I have been using it total for a year-and-a-half.  

The solution is not stable enough. If there are glitches in the process, it is not auto recovering from the issue. It is not even attempting to bring back a steady operational state. So stability is not sufficiently addressed.  

The product promises to be scalable. You can add multiple vRA's — as many as you want per what you want to do. But then again, you are bound by physical constraints. For example, if you want to have multiple vRA's with multiple targets, that does not work. They have to all be directed towards one individual target. It could be multiple data stores, but it still has to be directed to the same target.  

In one case, we wanted to extend to an additional target, so we initiated two targets. Of course, the targets had two different configurations, two different data stores, and so on. That will not work. So that is where scalability ends.  

We had to do a complete reconfiguration with new targets. Then push everything over to a new target, then destroy it again, and bring it back to the first. We have done that on a few occasions, back and forth, and it is quite a cumbersome process. It should not be the case.  

Again this particular case was kind of an advanced setup. But we also have tried some multiple vRA's with just one target. But even there we have encountered synchronization issues because they need to keep in sync, and it may not happen.  

Internal software synchronization issues amongst the vRA's paralyze the replications. There are some bugs in this functionality as well. We tried to patch them up using fixes provided from the VMware lab. Eventually, we ended up on version 6.5.1. Later on, those patches disappeared, apparently because VMware understood the patches did not fix the problems — or maybe created more.  

Because of all these issues, we are no longer using the product for the moment. This is because of all the problems and the fact that there is an ongoing license cost as well. I think at the peak we had 10 users. These were admins and engineers. I was using the product as a solutions design architect. But right now I would never use it unless it is for disaster recovery or rehearsal or something like that.  

The advice that I would give to other people who are looking into implementing this solution is that every software product comes with flaws. Products can evolve very rapidly. I think in our case that it was quite a good learning experience. It was a good learning experience for VMware as well — as they acknowledged. They said they would work on improvements in the various areas I brought up to them, and I liked that they will be making the effort.  

But if considering this product, I would also look at other compelling products, like Zerto, for example, or other replication tools like the Sun virtual platform. You could look at the ease-of-use of Nutanix. Their process for replication is very different compared to what SRM offers. But the ease-of-use comes with constraints. You do not always have the choice to have equal foundations for both source and target. Then there are backup solutions like Rubrik and Veeam. There are certainly alternatives out there that are categorically different product types with other ways to accomplish similar things. But a lot of what is potentially a viable choice depends on the use case.  

My recommendation would be to prepare carefully. Mimic your own live environment in testing as close as possible to the existing architecture with the vendor. Let the vendor prove that they are value-added resellers. Make sure you have tested in a representative set up at their facilities and can achieve what you are trying to achieve before going on to attempt to deploy and use it in your own environment.  

I do not think SRM is fully ready yet for a hybrid context where the workload is working across multiple clouds and on-premises. It is an evolving product.  

In a simple situation, the setup is a piece of cake. However, as soon as you start to work across various deployments based on various levels, the setup is much more cumbersome and much more complex. You need to deal with the interoperability issues like checking the vCenter on the left side and the vCenter on the right side, what is the ESX (Elastic Sky X) level, et cetera. You may need to downgrade your expectations accordingly, to make it still work.  

Also, if you have network routing in between two completely different, distinct environments, that can give you quite a lot of headaches as well. To give you an idea: in the initial setup of one migration, we could just not connect both VMs end-to-end. The site manager would not connect. The vRA's were connecting, but the site manager was not. It turned out to be a network routing issue. In actuality, the "issue" was not an issue. The routing was just was working like it should, following the default gateway. It just could never connect to the other site manager.  

At times you really need to go back down to the very basics yourself, and even then there may be no clarity about why it will not connect. It follows the route, the stage-gate goes through, and the connection does not happen.  

Then also the checkpoint restart is a problem. There is no checkpoint restart. What I mean by that is you can have eight VMs to migrate over a coming weekend and something goes wrong after the process is initiated, or somebody made a mistake in the service grouping. When you see this problem, you think you just need to remap, recalibrate, and then relaunch it. But there is no history track of what is already replicated. The service grouping does not reflect in that result. You need to start all over again. So there is no checkpoint for the restart. There is a checkpoint for an individual VM, but not for multiple VMs.  

As far as the time it takes to deploy, that will vary. We have had different levels of complexity in our deployments. We initially had a simple setup that was done in two days, but there were no different networks involved, no different vCenters, and also it was intra-cluster. When done like this it was very easy.  

It was a completely different story for the more complex setups. I think it took us about six weeks with a lot of effort. There was a lot of alignment, a lot of verification, a lot of troubleshooting, and a lot of diagnostics to get it working end-to-end on both sides. It was really too much time to take with that kind of project.  

On a scale from one to ten where one is the worst and ten is the best, I would rate VMware SRM as about a five. I am not open to giving a positive recommendation as the product stands. It is a little generous to give it a five considering all the issues.  

This review focuses a lot on the weaknesses of the product. But we were actually able to use the solution to get quite a lot of server images successfully, especially if the servers were relatively small, like a parasitic thermal server or an ordinary file server. That type of project went fine. So, if your use case is entry-level, beginning, and maybe intermediate, I think you will be fine using the product. But even if you do not have a lot of complexity and you try to work with this in a really big enterprise and a multi-region, multi-datacenter environment, you will have a lot of challenges ahead for sure.  

We have used it as a migration tool in support of a big transformation. I would think twice before using it for continuity on a permanent basis. I might think three times before more enhancements to the product are made successfully to enhance the utility.