Veeam Backup & Replication alternatives and competitors

We use MSP Backup & Recovery for just about any backup system, as long as it is running Windows or Windows Server.

We also have a couple of clients that have databases to back up. It does a very good job of automatically picking up an SQL or a MySQL database. If we need to restore just the database to another machine, although we don't have too many use cases for that, we have been able to do it when we tested it.

We use it for virtual machine backup and recovery as well. It does a great job of that. So even if a client has a host system and, say, one VM running on it for a special purpose, but they don't have the budget to pay for two backups for some reason, it does a great job of backing up the virtual machine itself, and it can be restored independently. 

A nice part about the SolarWinds backup and recovery solution is that I get to pick how it's deployed, and it's per-client. They really give you a lot of options with that. They pretty much have any feature that I, as an MSP, could want, and they let me choose how to provide their product to the client. I could cut out features if I wanted, which I don't, or I could add features as tiers to make a pricing bracket for myself to sell to them. I have one client that has a full, second dedicated server. It runs the virtual disaster recovery console, so it's constantly getting all the new backup images every day. If the first system goes down, the second system is able to bring it right back up.

I have other clients that just don't have that kind of budget. They simply need one workstation, not even a server, backed up. And they want me to be able to get either the files or the full image down from the cloud to put on a new machine. If the first one fails, they don't have the budget to have a disaster-ready plan where, if everything goes down, they have something running that takes it right back up. They have a spare computer onsite we would move things to. SolarWinds gives me the options to do both things very cleanly and to please those different levels of clients, without having to jump through too many hoops.

It does everything I want. I feel a lot better with it because I've already used it in the recovery scenarios and know it works and I've got guys testing things on a regular basis. The clients are happy because they know that I'm happy with the solution, because I'm usually going to suggest it over something else. It just makes everything so much easier on the backup. There used to be so much anxiety with other solutions because they were so much harder to manage.

This gives me a dashboard with a bunch of green, yellow, or red lights based on how things are going. I can put technicians into action based on things failing or not updating properly. And the few times we have had things go wrong, it has been easy to communicate with the client quickly and make them feel that we're very on top of it and aware of this process, just because of how the system is set up to work.

In general, we used to have to have that "backup conversation" with a client, every once in a while, to see how things were going. Now, because this is our baseline of how we expect things to work in a perfect world, even if they don't have this, it's made our backup documentation process easier. We tell the customer, "Hey, this is how it would work in a perfect world, but this is how your system works. If you want to get closer to where it could be, here are some things we can do." It has made it easier to talk to the clients about the options that they have.

Before, I didn't have a whole lot of confidence in the solutions we had, compared to the confidence I have in this. That lack of confidence in the products we were using made it harder for me to even have that conversation with the client. SolarWinds has just completely flipped that around, and that's true for other people inside our org as well. Other people were having the same grievances I was. It was hard to find a good backup solution where it didn't feel like we, as the MSP, were getting shafted in some way and we were having to charge the client a lot more because of that. It was especially true when you get into how a lot of vendors price their cloud backups compared to SolarWinds. It's absolutely crazy when you look at the cost comparison. So having that extra confidence and being happy with the solution has really changed the entire game and that's because of how it is priced and how they let us present the product itself.

The cost for the customer has gone down because we don't have them buying as much. We don't run a second recovery computer at many locations, unless the system is vital to every operation, because we have the Local SpeedVault that we use. It's either an onsite NAF or an external hard drive that stores all the stuff locally for the machine it would need to restore to. It gives us a really good, fast solution, compared to pulling it down from the cloud and messing with their bandwidth, especially if they have VoIP phones. The cost of investment has gone down. For a few niche customers that are much larger, the cost has gone up, but the return on investment, as far as data security goes, is much bigger. Previously, if I would have had them invest that much in another product, I wouldn't have felt good about it. But asking a larger client to put in a second server, so I can always push their stuff out right away if there is a failure, is a pretty big deal. By comparison, with Carbonite I actually had that set up, but when I tried to use the tool not only could I not get help using it properly, I never got the thing to work. With SolarWinds it was so simple, it felt almost too easy.

In addition, there is much less of a time investment from my techs, compared to before. That's the nicest thing it has changed in our everyday operation.

And for me, it has drastically reduced the amount of time spent on backup administration. We had people spread out on different odds and ends for different customers, for whatever solutions the customer wanted. We didn't have one solution. Between keeping things documented as well as I could, as a one-man show on that end, and actually being able to test stuff, if I could test stuff, and always trying to figure out the products, I'm probably saving a good 10 hours a month, if not a lot more just on that. If I had kept the solution we had before and grown to the number of customers I have now, I don't doubt it would have required another whole employee to manage things, with the amount of backup and the different solutions that we had to use. This one ended up bringing together any use cases somebody has, because most of our customers are running in a Windows environment. It fits their needs perfectly.

As for backup time on the computer and how long it takes to run, it's insane how much quicker it is compared to constantly having to check back and forth between what's going on on the computer and what I see in the cloud. Carbonite had poor solutions for looking at what was actively happening. With SolarWinds, after I install it on the computer, I never have to log in to the computer again, if I'm working at a higher level where I'm not interacting with customers. I can always pull up these backup systems remotely from the cloud. I pull up the system, it pulls up a webpage, and it gives me the percentage it's processing and how much data that actually is.

And if my local is synchronized with the cloud, I get to look at all this data in one place, compared to going back and forth between a local computer and maybe a website and one other thing. It's all in one spot. I can manage every computer from an easy console. It has probably saved 55 percent, if not more, of actual employee time. It's not something I've actually calculated, but I am the person who was spending that time before, and that's when we were supporting way fewer clients. We've grown this product with us as we've added people to it. I don't think we have many customers with an important local system that we haven't gotten to move to SolarWinds, unless they've outright refused to back up what they have.

The backups themselves seem to run much quicker, even though they're going to the cloud. It has two different phases. The time it takes to process the backup on the computer is quicker, especially if I've got my Local SpeedVault there, or my secondary system that is acting as a speed vault to bring it back up quickly if the system fails. Having either of those there, it gets done within minutes, most of the time. There have been very few times where I've seen it go above 30 minutes, and that's on a bigger system and when they had a lot of stuff going on that day. On my old system, I'd be watching this program take time to launch, run the backup job usually it would make the shadow copies first. This seems to do all that stuff so much quicker.

On the other end, it uploads to the cloud. If I did have a manual upload to the cloud before, or was using something like Carbonite, this seems to get to the cloud quicker than those. And if it's going to a local hard drive or a local secondary system that is a failover, it's stupid-quick. It's the difference between looking away for a little bit at another task while it runs, and it's done, compared to keeping another computer up or another page up with a loading bar for a bit, while I'm constantly going back to it and waiting for it to finish. That's the difference it's made in my every-day.

When it comes to recovery times, I'll give you two different scenarios. In the small scenarios, where just files or folders have been lost or deleted and we need to find them and restore them from within the last 30 days, it's gone from 10 minutes down to closer to seven or five minutes, because we know exactly where to go. Every one of our techs who is trained on this can get there super-easy. They're not having to memorize three systems.

The other end is the big scenarios. I've had an entire server go down or a natural disaster that has stopped the business from functioning, and I needed to get them up and running one way or another on a completely separate computer. I was only relying on my cloud data to do this. In those scenarios, it has reduced our recovery time by a minimum of 12 hours.

The difference is quite crazy. Before, even if I could get stuff down to another server, I had to install the server OS and get stuff running. I had nothing else that did a good virtual disaster recovery in the big cases. Virtual disaster recovery is so big because for any system, no matter how complicated it is, I can already have a server running that has Hyper-V installed, and I can get this thing up and running with Hyper-V within a matter of hours. Sometimes, it's less than an hour, depending on how quick my download is. Really, at that point, I'm limited to: Do I have local data I can source from as far as the backups go, or am I only going from the cloud? If it's only the cloud, my biggest limit is my bandwidth. Going full-blast at our shop, if we let that server do that, we can get somebody up and running in less than an hour, even if they have something like a 200-gigabyte setup. On a larger server with multiple terabytes, it does take longer. There's no way around that, unless they have that secondary system set up onsite. But for the people that do have that, I manually log in and start that secondary server up. I literally click a button and configure one or two things and I'm good to go. It's insane compared to before. I did not have a solution that came even close to that, a couple of years ago.

The most valuable feature by far is the Virtual Disaster Recovery. On top of that is the bare-metal recovery. The recovery options that we have are great. We have tested the Virtual Disaster Recovery and the bare-metal recovery in just about any scenario you can think of. We have even restored bare metal, a full server, to a laptop, and had full functionality. It's just insane how well it works and how simple it is. It does most of the work for you. I don't feel like I'm thinking too hard when I do this. I understand how the system works on the back-end, and what it needs to do, but I don't want to concentrate on that when I've got so many other things going on. This really does just so much of the legwork for me.

In terms of other types of recovery scenarios, it covers something as simple as somebody who has access to a shared folder and they delete a file on it because they weren't thinking about the fact that it's for everybody, not just for them. That's the scenario where, if it's within 30 days — because this has a 30-day history for backup — they call me and tell me that they deleted the file. I just ask them for either the file name or location or as much stuff as they can remember. I log in to the backup system from my console, get into the recovery part remotely — I don't even have to log in to the workstation hosts or the server host — I find yesterday's file and folder lists from a nice calendar view, and then I find the file that was there. I click it and restore it to the machine. I can restore it to a different spot if I want, but I usually just choose to restore it in place. I call them and confirm it's there. I've never had to take more than five minutes. It's quite nice for doing basic stuff like that.

A more extreme case was when we had somebody's entire system go down and we were able to virtually restore it, no issues whatsoever, getting it running offsite. We were able to link them up on a VPN until we got a temporary server there and fixed things, because they had a catastrophic failure. Luckily it was a simple server, so it wasn't too much work, but it was nice to keep them up, with their domain, in the meantime.

The most complicated recovery scenario is a host machine running multiple VMs, where we only have the host machine, itself, backed up. This is somebody who doesn't want to pay for the second server onsite, so our company has temporary servers. We're very physically close, meaning we can do a bare metal restore or a virtual disaster recovery and get everything they have up and running within about an hour after the failure. That is one where we have the file folder system state and VSS backup recovery running and, no matter what fails on their system, we can get it back out. Even if it's not full system failure, we can restore most things remotely. If it is full system failure, even if we have to bring it to a different site, we can get the data down within about an hour and then get it to wherever they need.

SolarWinds is very flexible and lets us do things the way we want to and we can do them quickly. For the clients that don't want to pay for that extra stuff to get it done quickly, we can explain to them that it's going to set things back this much. We really let our clients choose how they want to do things like this. So if they want a backup and recovery system, this one is very easy, because it's paid month-to-month and has very specific data caps and overage charges for those caps. It's super-easy to lay it out for any level of client, be it a one-person operation or a business that has 300 users and allows "bring your own computer."

Depending on what they have, we can give them an easy projection of what their investment in a system like that would be. There won't be any surprises such as, "Oh, we went over 1 terabyte, we now have to get to the 5 terabyte cap," which is something I had to deal with when I used Carbonite. Instead, if I go a gigabyte over the standard cap for a server or workstation, I pay a set amount of money that doesn't scale up or down. I know exactly what I can do with this solution for any client. I know exactly how much I can charge them and it's done monthly. It's easy for them to drop in and drop out on a monthly basis if they're nervous, because they're not dealing with that annual commitment that a lot of solutions shove at you, even if you get to pay monthly. That's a really big advantage in terms of peace of mind after it gets running.

And all of that is aside from the fact that they give you free archiving, which is really nice. Not many other solutions do that, cost-wise. I get to do as many archives of a system as I want and it doesn't count against the data for that user or customer.

It also gives me a single dashboard for all types of different sources it's backing up, such as databases, files and folders, system state, etc. It gives you your entire client list. It gives you a daily update of green, yellow, or red. Yellow means something kind of went wrong and maybe you should look at it, but wait. Red means something definitely went wrong and you need to take some sort of action to adjust. Green means every single thing worked properly, nothing had any errors.

I get a daily email that I'm able to integrate into my ticket system. The tickets come in only if anything fails. If something fails, my technicians get details of exactly what failed with an error code. And if I go into the console and look at the error itself, it gives me details and a resource center, from SolarWinds, where I can look it up. I can Google from there and figure it out.

That kind of information has made our backup operations much smoother, especially because the few times the Help articles haven't answered something for us, support has eventually gotten it to work, even if it seemed like a niche situation where we've got five other clients deployed like this yet one of them is having this really odd issue. SolarWinds support has been able to dig down. I have sent them logs and they've looked through them — hundreds of lines. They highlighted one, showed me what was wrong, told me what to fix, and it worked after that.

A better default view on my dashboard would be great. There is a lot of useless information there that it pulls up. They could present the dashboard slightly better, in terms of the extra information after the first five columns. The first five columns are awesome. After that, I don't care about the rest, and there are another seven things after that. You can customize it, and I do have my own customized dashboard, but it doesn't give me any option to make that the default view.

They could work a little bit on how they present you with your landing page. The first time I log in to this from any login window, I want a page that's a little bit more useful. This one gives me great info as to if my backup is good, up and running, or if it's had a certain number of errors. But after that, it tells me stuff like my product, which I do all-in for all our customers, so I don't care. It tells me my profile and I usually do a manual setup for most customers that's documented on my documentation system, which is also with SolarWinds. So I don't care about my profile version. All that stuff which is extra, that I really don't care about, is on this default view, and they don't let me save my custom view as my landing page. I have to go and find it again. It's deep down inside a menu at the very bottom and I can't make it go anywhere else.

Another point to be aware of is that the initial cloud backup, if you've got more than a terabyte of data, can take quite some time, because it's completely dependent on the customer's internet speed. That is one thing that we have run into. When I asked SolarWinds about that they noted they already have a solution for that.

Since deploying it, there has only been one weekend where there was a stability issue, and that only caused a problem for one of our 24 clients who are on the solution. It cleared up the next day.

The scalability has been nice. I have had a system grow with this and I've had no issues. I'm not going to pretend that I've got a customer that has nine different servers or that I have 50 clients. But when I've had a single host server scale up its usage, this has handled it just fine. I've also scaled up the number of customers I have on the system. Both have been easy to work with. Scaling up the number of customers I support on my end has been easy, and scaling up the load on an individual host, running a large backup, has also been easy.

We're actually making a large push with most customers, if they have a system that requires it, to use something like this. Our criteria for them "requiring it" is that they have some sort of locally hosted program that is accessed by people at the business and that it's required for everyday use. If we've got somebody running QuickBooks off of a workstation, and they're really worried about backup, the workstation backup is priced well enough that it's worth having that always-up availability.

I generally don't go to tech support until I have a really serious issue. But the times I have gone to tech support, they have given me good information. Even if it didn't directly solve my issue, it helped me to solve that issue and it was good info to have in the first place. If they needed to escalate the ticket, they did so properly and fairly quickly, if not quickly enough in all cases. It's definitely better than a lot of other tech support I've dealt with.

We have been using SolarWinds MSP Backup & Recovery since the middle of 2018, when we started to need a recovery solution that was a bit better than what we had. Before we were using a custom solution of saving Windows backups to the cloud and to a local device. We had options there for bare-metal there and file recovery, but nothing that was overly reliable or easy to test.

I have found the initial setup to be incredibly straightforward, especially because of the tools it provides you with. There are "how-to's" everywhere. I'm logged in to my dashboard right now. My name is up in the top, right-hand corner. There's a big question mark right by my name. I click on it and I immediately have two big sections: Help and Resources. Help has all the manuals, how it works, and a live chat if I get stuck. Resources has my sales guide, my downloads for any product I need, and my About The Product section.

Any info I need about these products is immediately available, just like most of SolarWinds' other products. They do fairly decent documentation or, if they've bought the product, they keep the documentation and move it over to their systems pretty well. And they give me the live chat when I get stuck, which has been helpful.

Setting it up generally takes me about 10 minutes, even if the system is large and complex. It's 15 minutes, tops, if I am dealing with it taking a long time to spin up or download something.

Because I do the training on this in our company, for the most part, I have already set up training for the standard operating procedure for deploying this backup. It's a four-minute video with some notes that the techs can use if they get stuck. It shows the entire process, from creating the customer inside SolarWinds, to adding the device, and getting on the device and deploying the backup itself. The nice part is, if there's a person who needs to work on the computer — because you can do this on workstations that people need to use and it works super-great — we just download it and install it really quickly. Because it becomes available in the cloud to configure, all my configuration can be done remotely without interrupting a local user.

To deploy the solution for one customer, it requires just one person. With all the customers we currently have on this, about 24 customers, I've got three techs handling it, including checking on the system, running restorations on a quarterly basis, and physically testing those restorations. If I didn't have to run the restorations, and that's something our company just chooses to do, I would only need one person for this whole thing. As it is, it's me and two other techs, one who is a level-2 and one who is a level-3.

It's a set price for servers and workstations, so we're able to charge our clients an amount that is a fixed percentage above our cost.

The previous backup and recovery methods cost so much that we would mark up our cost to the client quite a bit less, in comparison. For example, with Carbonite, we were probably only marking it up a fraction of the markup we can charge now and, when I needed Carbonite to work, it didn't. We want to treat our customers right. We have really good relationships with them. We know a lot of them, even though we have so many, and we don't want to feel like we're doing them wrong. At the same time we have to pay our guys.

We had previously tried out using Carbonite for Windows and Windows Server backups, but we were getting very poor recovery results. The backup always gave a green light, but when we actually went to recover in tests or real-world scenarios, we were missing stuff. And there was not much help or explanation as to why, if we reached out to support. That went really poorly. We made a hardcore switched to MSP Backup & Recovery after. Because it's able, for a really good price, to recover in just about every scenario — even crazy ones, in the real world and in testing — we switched over to this and just didn't look back. If it's running Windows Server or Windows 10 or Windows 8, etc., we're going to use this to back it up if the client needs a backup.

Before I licensed SolarWinds, I looked into Datto and Veeam. The differences between those solutions and SolarWinds MSP were commitment and pricing. The features were there. I'm not going to say that the products aren't as good, but they were not priced competitively when I consider my customer base. 

I'm sure it is much different with somebody who has super-large organizations that they support. I would guess that they would end up going with Veeam, because Veeam is, honestly, a good solution. But when it has to account for anybody, from the small, one person operation, to the organization that has a domain and 300 users on it, Veeam doesn't work for me because I can't price it well for everybody. That's especially true when it comes to including the cloud backup solution. I liked Veeam as a solution but I did not like Veeam's pricing, comparatively, especially when I added cloud. The big differentiation was that cloud is automatically included with SolarWinds' solution. Not only that, but the cloud and the cost of using the software is all bundled together. If I go over the set amount of cloud storage, I pay an amount per gigabyte, so I can gauge that really easily. 

On top of that, when it comes to the pricing structure, SolarWinds does things that it seems would be counterintuitive to their making money, and that was impressive to me, because I'm used to most vendors doing the whole "cash grab" thing. First, they have incredible deduping. If duplicate files on the system get uploaded, they make one source file that gets uploaded and it links back to the multiple spots that it was copied from. This saves time and this also saves money. It's crazy that it works this well. These are scenarios where I was worried about restoring them, at first. I thought, "It doesn't seem like all the data is there; it's only backing up one-third of the total storage on the server." But no, it all worked perfectly. Everything is there in the full amount. So they even reduce the amount of money they could charge you for data overages by reducing the amount of data that they put on their servers.

With Datto and Veeam, it felt like I was paying for the software, and that once I got the software I would have to figure out the rest myself. With SolarWinds MSP, it felt more like I was being given a solution. Everything feels like it's tailored and included. With the other systems, I really felt like I was on my own. Datto's prices were not so great, so I went away from them really quickly and looked at Veeam. The impression I got from Veeam was, "Hey, we're Veeam, we've been around forever. Everybody knows us. Figure out how to use it." And if I wanted cloud storage it was so much extra. And it wasn't per gigabyte. I really didn't like the pricing structure and model they went with. Because it felt like I was paying for the software and everything else was an afterthought, something like SolarWinds, where the software is bundled with the cloud storage was really nice for me.

The biggest lesson I've learned from using MSP Backup & Recovery is that there are options out there that I can be confident in, and I don't feel like I have to break a customer's bank to offer them. It's a really big deal for us to be able to do that. Having tested it and used it at this level, it's changed so much how we view what can be done, for keeping even our small customers' data safe. Before, it felt like I had to do a lot of extra things for the smaller places, because they couldn't afford the solutions that were better. Now I have something that I can trust to just do that for them. And it's so easy to maintain that it's really hard to look back and see that we were using other stuff before.

My advice would be to understand that the features are there. Price it out, compared to the other solutions. Because they give you such clear-cut pricing with the system itself, it's really hard, when you get down to dollar and cents, for anybody else to compete, in my opinion. The only use case where that changes is maybe where many terabytes or petabytes of data are included, and you do not need a cloud solution. In that case your cloud solution is some sort of data center or solution you've set up yourself. If you need to back up to the cloud, and this goes for any size organization, and a data center is not an option, SolarWinds is something you have to consider. At least to price it out, especially considering you're never under any commitment, even if you want to try it for a month on one system. The worst case would be that you would get charged for a month of trying it out. 

What I did for us, beforehand, was that I tested how it worked on our systems. The R&D for that, for researching that and figuring it out, is $10 on a workstation, or $50 for that one month. How are you going to compare that to anything else, where you have to sign a contract? You might get a trial, but it's unlikely that you are going to be able to figure everything out in that time. It's so much easier to work with, in all aspects that I can think of, specifically as an MSP. It's not that I think this is the solution for everybody, but for MSPs that don't support incredibly large organizations, this is perfect. It is exactly the solution that I wish I had found years ago.

When it comes to resource and bandwidth use in terms of backup recovery, for the most part I have not yet run into an issue. The one thing I have seen is a light blip on the VoIP. One time, when I was new to this and I restored a grouping of folders for a customer, while it was pushing stuff down we had some reduced phone quality. That download was taking up some of their VoIP. People could hear them fine but they were getting some static. 

What I found out is that there's an option to limit bandwidth during the day. For every customer now, when I install the product, I just do a quick audit of their internet speed. Based on what they can get, I give the download and the upload a percentage of that, so that it won't affect other systems. The bandwidth usage is completely customizable. If you want it to, it'll use your whole connection to get something important, and you can change that on the fly. It's not like it takes time for those settings to push down. But if you want good, everyday operations, you just limit it to a healthy percentage of the bandwidth during the day, and you're good to go.

I am not using it to sell the automated recovery testing and I do not like that feature. I believe it has more of a risk for a false positive than anything. I have done the testing internally up until now with a team. When we have issues, we work on it as a group. We're all very aware of some of the pain points of restorations. One of those pain points is that, sometimes, that virtual disaster recovery is so good that even if I had a technician that did not configure a backup properly, if an error was made on our end, I don't get to see it because the virtual machine will spin up almost no matter what, Windows 10 and past. This system is that good. Even if I have a messed up computer that got backed up, it will still run and work and I've got to do a little bit more digging to figure out if it has an issue.

I had exactly that happen; not in a real-world scenario, but when our team was testing. I could have just said, "Okay, I'm going to do recovery testing and give you a green light when the VM turns on." It can do that. This system is so great that it can turn almost any VM on. This is more of a personal philosophy for how our company runs stuff, as opposed to the viability of the tool itself. SolarWinds does the most that it can really do, without manual interaction from a human being. It does a good image test to see if all your stuff is there and if the VM turned on. But if you do that and it allows you to become complacent, you could miss backing up the drive and never know it. We actually almost had that happen and it might have if we didn't do our own recovery testing and check for stuff like that.

Overall, I would give SolarWinds MSP Backup & Recovery a good 10 out of 10. There is not another product in the SolarWinds line of products that I'm happier with. This is the best of what they have, and I use almost every product they have, except their antivirus.

The highlights of this solution are the way that they price it, how easy it is to use, and how customizable it is. I get to choose exactly how I want to use it, since it comes, default, with every feature. I get to choose how I present it to customers, if I want to do that. This is a good product that's really fair, and it's not complicated.

We are an IT support company, so we resell IT and support services. It is our customers who have installations of disaster recovery appliances and cloud backup solutions.

We are our customer's IT support company. We are the ones who implement and support it. Our customer pays the bill, but we do all the support, looking after it. I do not back my own data up on Infrascale, but I definitely back up my customers' data.

We sell and support two products for our customers. We have four disaster recovery appliances onsite that then back up to the cloud from the appliance. We also have quite a few people on just the cloud backup. So, we use cloud backup and DRasS, which is disaster recovery as a service.

When there is an appliance-type installation, which is a physical hardware installation, we go to the site and install a piece of hardware. That piece of hardware communicates with their servers onsite. Their servers are hosts with virtual servers built onto them. The complete virtual machine is backed up maybe twice or three times daily to the hardware appliance provided by Infrascale. That could then become a replacement for the server, if the server had a physical problem and needed to be shut down. We can turn the physical server off onsite, go to the appliance provided by Infrascale, boot up the virtual machine on the appliance, and then it would run the business as if the server were still running. So, it is hardware redundancy for the server.

It backs up the virtual machines, backing them up and all the files. So, it can be a data recovery tool as well. Also, if the entire building burnt down, we could jump onto the version in the cloud, boot that up, and people from all around the world could log into that server to carry on working.

Imagine an appliance, similar to installing a second server, that backs up a virtual machine to the appliance. It has disk space on the appliance, then it backs up that virtual machine from the appliance to the cloud. Our cloud is based in the UK, which is also provisioned by Infrascale. So, we implement that sort of system, which is a little bit like SaaS, but it is a disaster recovery solution. We also have cloud backup, which is a software installation to a server, that then backs up certain files and folders through a cloud provision somewhere in the world.

We are the actual customer because we sign for these products, and our customer doesn't. We are the actual people who lease these things from them.

Now, if one of our businesses has an issue, I am confident that we would be able to get them booted and running within a couple of hours. It would affect their business, but it is a disaster recovery scenario, so there has obviously been a disaster. 

The recovery of data is the most valuable feature. The software backup, which is just a program that gets installed on a server, can back up to the cloud. You can install that on a server or PC, and that will simply back up a user's files and folders. If it is installed on the server, we just back up the relevant data. Recovering that, if there has been a malicious attack on a business or anything like that, has been invaluable in the past. The good features about that are obviously, if the physical hardware has a problem, then we can utilize the appliance, turn on the virtual machine, and carry on running the business while we put the hardware back and correct the issue.

The Boot Verification feature gives you a snapshot picture to tell you what would happen if a virtual machine was booted. From that, you can tell whether the backup was successful. 

I find the dashboard fairly straightforward. It is fairly in-depth from day one. The more you use it, the more you get used to it. I find it fairly straightforward now for making some limited changes that won't really cause any problems. It has a good user interface.

The speed of the solution’s restore functionality is very quick. It works a treat and does the job perfectly. I don't think we have ever come to the point of thinking the product isn't quick.

We did have a major problem last year in March. Somebody attacked some servers being supported by Infrascale and managed to wipe the servers as well as wiping the appliance. However, they didn't manage to wipe the cloud. So, what was on the cloud had to be downloaded to the appliance again. The customer was probably down for about three days. This was a very difficult situation for us to be in.

I think somebody had accessed the server, could get onto the appliance, and see what it was because we had saved the password. Now, I know better than to save the password. Also, the password was still the default password. With the new implementation, it makes you change the password so you can't keep the default password. However, four years ago, when we implemented it, the default password was still on that appliance when that appliance got wiped by somebody.

While this would be a very worst-case scenario, I don't blame Infrascale for the amount of time that it took. However, it was difficult for us because we were trying to placate our customer, which was difficult, because they have a 25 million pound turnover business. They were not happy, but we are still working with them. 

I think I'd be more confident now dealing with the problem. Plus, we monitor the systems more closely. Whereas, previously, I presumed that everything was going well without really checking. Now, I have learned that I need to be on top of any issues. So, I am checking the appliances and cloud solution backups daily. So, we are a bit better switched on with supporting it.

When you are ordering hardware appliances, they have to be delivered from America. In the past, hard drives on the appliance have been simple SSD drives that are installed. However, they don't have a local supply for the SSD drives in the UK. They have to be exported from the US, arrive, and then I have to go and install them. Then, they will rebuild it from their side of things. However, I could order that same SSD drive online and get it the next day. So, I have to wait days for things to come when I could get the exact same drive the next day in the UK, if I wanted to. That causes a bit of a problem. I don't know how many businesses they have in the UK, but I do think that having to import stuff from the US is a time-consuming problem. If there was a holding in the UK, then we wouldn't have that delay in time.

When they export stuff to me from the US, invariably the delivery company (called DHL) is looking for EORI numbers that we don't have. So, they try to involve us in the export of it, and it has nothing at all to do with us. We are simply the customer. If I had to moan about anything, that would be it.

Where the dashboard is concerned, I am okay with it. I am looking at one now and understand what I am looking at. When you first get in it is difficult, but I do believe that they now offer certain training for it. Given the fact that we are trying to support our customers in the UK, it is good to have the knowledge about it, know what you are looking at, see what the size of the protected bytes are, and understand it a little bit better. I have been doing IT support for implementations for the best part of 30 years, and it took me a bit of time to get my head around some of the way things are done.

I have been using Infrascale for over four years, since April 2017.

It is very stable. I have never had any problems with the software. If we install the software on anything, it does what it says on the tin, which is that it will run a backup at a certain time. 

There are some issues with the software backup. Those issues are it cannot back up from an installation onto a server nor can it back up redirected folders on a server. Because when you install the software onto the server. you are installing it as an administrator on the server. However, an administrator account on a server does not have access to a user's redirected folders. 

The user is actually the owner of that folder on the server, even the administrator can't break into that. While you can force your way in, it basically breaks the policy, so we don't try to do that. If we had to, we could. However, out-of-the-box, installing software onto a server, it does not back up people's redirected folders. Now, if you are a user that saves a lot of files and folders onto their desktop, you get redirected back to the server. Essentially, you are missing quite a bit of data to be backed up. So, we do get a lot of errors based on that. We have found a little bit of a workaround. However, that workaround doesn't always work either, causing problems.

I check daily that the backups have gone through. If the backups aren't working correctly, I log onto the appliances and check why the appliances haven't backed up correctly. If it is something that I don't quite understand, then I will pass that down to the support at Infrascale. Where the appliance and cloud backup are concerned, there is very little maintenance to do. 

We have had problems with this. Again, this is down to us not really understanding the product in the first place. In the case of the company, where we had problems with last year, when it came to bringing the VMs onto the appliance, we had to download them from the cloud. We got the VMs back onto the appliance, then we found that trying to boot them and the hardware was insufficient to support their product. So, the product ran like a dog when it was booted up on the appliance. So, it was unusable for the customer. That was down to us. When we were trying to size the product, it was a misunderstanding of, "What would be the minimum that would allow this server to run?" Well, we know that the minimum a server will run on is 8 GB. However, when the customer's product is on there, 8 GB is insufficient to run the server. So, it caused some problems.

One of our companies, who has had the product for three years, is at the point where I don't think the appliance has now got enough space to back up what they have. The only way that we can do anything with it is to keep getting rid of backups, which we probably shouldn't do, but that is what we are going through at the moment. So, we have to really micromanage the backup that is happening so it doesn't go over. The customer could upgrade it, but our customer isn't realistically going to put his hand in his pocket and pay any more at the moment.

For all the people that we have on it, we have six terabytes of space in the cloud for the cloud backup solution as well as four appliances. I am the one who looks after all of it. I monitor it, and if there is a problems, then I deal with it. The guys who work for us run the IT support side of things, and I look after the backup side of things.

We have a couple of thousand endpoints. We are quite a small IT support company.

I am perfectly happy with the support that I receive from Infrascale. The technical support is very good. I deal mostly with one guy there called Maxim. He understands what the issues are and is very helpful. I mostly deal with one guy there, who is fantastic. 

They work in the Ukraine, so there is a little bit of a language barrier. When we first started working with them, I found it very slow to get my message across. Things have improved. What they have done is given a certain person for me to always deal with, which suits me and I'm happy with that. You develop a bond with the person and know that they understand your systems. Previously, when we first started, we could get anybody. Then, we would have to go through the same process of explaining things all over again. To start with, it was like pulling your own teeth out, but now it's improved.

They are proactive to the point that Maxim will check my system. If he sees something he will log a call with his own support desk. He phoned me up the other day, and I said, "Hello Max, how are you doing?" He said, "Yeah, good." I said, "I've seen a ticket was logged, but I haven't logged it." He said, "No, I logged it for you. Because I noticed something was getting high, and I wanted to have a chat with you about it." That is great, because that is proactive monitoring.

When we first started to do the appliances, I really didn't understand what the service was. I thought it was a managed service for backups. I didn't realize that it would be me who would be managing it. But, the more I have been involved in it, the more I have become accustomed to managing all of its appliances and installations. I take the responsibility for making sure that it works. Support-wise, it has improved. I have seen the business improve over the last 12 months. I think the business got sold or bought out. However, there have definitely been recent improvements with the support.

If I am ever going to do anything that I think is outside of my remit, I will contact support and go through one of their support guys.

Nobody from Infrascale has ever phoned me up and said that they want to test anything.

We used Veeam Backup. Mostly, we would use Windows Backup to USB drives.

I switched to Infrascale because I wanted a solution that gave me what I was looking for. Backing up to the cloud directly from your server causes slowdown. I wanted something that would allow me to have an item onsite where we could quickly back up, then slowly back it up as needed for it to be in the cloud, as long as it did the job. I checked online, had a look at what customers were using, and read through some stuff for Infrascale. It just clicked that it seemed to have what I was looking for. So, I contacted them and never had a problem. I did the due diligence myself, so I am happy with it.

Now, the initial setup is simple. Years ago, when we first started, it wasn't simple.

I installed an appliance yesterday and had it installed within an hour. From the box to the customer's site, it was installed and ready for the next stage. Then, one of the implementation guys from Infrascale gave me a call, and we liaised with each other because they like us to set it up. 

They tell me what they would like me to do. Now, the setup is much easier than it was when I very first had an appliance. It seemed to take forever when I first had an appliance. However, yesterday when I did it, it took no longer than an hour.

Because I have implemented these a few times now, I have a bit of knowledge based on some of the things that you come up against when it comes to making it all work exactly the way you want. There were things yesterday that I knew we should check to make sure it was working, because a couple of the backups failed to start. I actually told the guy at the other end, "Let's try this." So, we tried something and made it work because of the knowledge that I have built up. It is a lot easier than what it used to be, because it used to be difficult. Now, out-of-the-box, it is fairly easy.

When we install a hardware server, we build that hardware server with virtual machines on it. The hardware physical server would be clustered at the host with Hyper-V installed on it. Then, we would build the virtual machines on it, and those virtual machines are essentially the servers that are onsite. For customers of a certain size, we wouldn't suggest this because it is quite expensive for our customers per month. It is a fairly expensive product. However, for customers of a certain turnover, we would suggest this. We would explain to them in full what the disaster recovery solution offers. What we say to our customer is, "Our backup strategy would be to backup between two and three times a day, which would be before business starts, as business ends, and during business hours." So, any one of those would be bootable and the files are recoverable from three sections of each day. So, that is our backup strategy, which is really based on the appliance. 

I help with the implementation. In fact, I implemented one yesterday with some of the guys. Sergei is the implementation guy. So, we did an implementation of an appliance yesterday. I do a lot of the support for my customer, utilizing the support services of Infrascale. I deal with a guy called Maxim on a lot of cases. I deal with it directly with the guys at InfraScale. 

They have never physically tested any of our systems. Infrascale has never tested anything. I have never had a phone call with them to say, "We want to run some tests on something." We have installed the stuff, but they have never tested it. There are no tests.

I make sure that this all works. While it does cost a lot of money, it is a good service. I am well bought into what it can do, because as much as it protects the customer, it protects me as well. If we had not had this solution 12 months ago, then the company that we support would no longer want us to work with them, because they would have nothing at all. So, it saved us.

We pay 600 pounds per month for six terabytes of cloud storage and backup. This is a fixed cost of 100 pounds per terabyte.

We pay 752.50 pounds for two appliances, one of them costs 301 pounds per month and the other one costs 451.50 pounds per month. 

Another appliance costs us 327.60 pounds. 

The newest appliance that we installed yesterday is costing us 511 pounds per month because it has better speed and memory. 

The appliances have different prices because of storage, size, and memory. For example, the older machines support more virtual machines, whereas the new one only supports one virtual machine. As we have purchased the later appliances, they have probably been a little bit more expensive because they have to be good enough to keep the business running if the physical server goes down. We learned our lesson from the one that went down when we tried to run products and it wasn't quick enough.

I push it in my own business. I wouldn't do that if I didn't think it was any good. I would definitely advise others that it is a good product.

If you want to back up redirected profiles on a server, you have to go into the scheduler and change the event in there to be a system event, and not run it as an administrator. That is the best thing that I learned, because that enables you to back up redirected folders. However, if you sign up for Infrascale, even they don't know that. So, you can get it to work, but it takes a bit of messing about to do it. If I had to say to somebody, "Get Infrascale, put it on your server, you can back the data up, and then you can back up the user profiles. You will need to go into the scheduler and change it for the task to run as a system event, and not as with administrator rights. It has to run as a system, and it will then work."

The speed of Infrascale’s backup functionality is good. I have had no complaints. The speed of backing up to the cloud using the software solution is based on the speed of the server at one end, how quick it can run the program, and the upload speed of the site. Realistically, that has nothing to do with the solution provided by Infrascale. Where the appliance is concerned, because the virtual machine is backed up to the appliance, there is no lag on the servers from the appliance, which then backs up to the cloud. That is based on the speed of the customer's bandwidth, because that is how it gets into the cloud. Solution-wise, I think the speed of it is just fine.

The speed of recovered documents is more based on a customer's broadband.

After a few weeks, anyone working with Infrascale should really understand the product, and it should be fairly straightforward. 

We offer it to all our customers. It depends on whether they are prepared to spend any extra money on the solution. So, any new customer who comes onto us, we suggest that they have an offsite cloud data backup that will protect their data only in the cloud. Then, should anything happen, it's recoverable to a drive and we would be able to give it back to them. Backup is a service, and it's also something that they can do themselves locally. We do try and get as many customers onto it as possible because it helps us.

There is a slight language problem. It is a bit hard for people to initially get used to, because support is in the Ukraine. I think the language barrier would mark it down one point, but it is a nine out of 10 for me.

We use Nasuni to provide storage at various locations. It is for office-type files that they would use for day-to-day office work, such as spreadsheets. None of it is critical data.

Each group at each site has its own data store. For example, HR has its own, and finance has its own. All of these different groups at different locations use this data, and they use these filers to store it.

The Nasuni filers are on-site, and we have virtual edge appliances on ESX servers at about 35 sites globally. The data stored at these sites is then fed up into Azure and we have all of our data stored there.

The OR and DR capabilities have been a very big help for us. Previously, with the solutions we had, it would have taken weeks sometimes to get things fixed and back up and running for people. Now, it only takes a matter of minutes.

It used to be a lot of trouble to bring data back up and a lot of the time, it was read-only, so the people couldn't use it very well. Now, with Nasuni, we're able to pretty much keep their experience seamless, no matter how much trouble the hardware is in at the site.

The Nasuni filers are easy to manage, although the process is similar to what we had before. We have a report that comes out three times a day that gives us the amount of data that's in the queue to be uploaded to Azure on each individual filer. We keep track of that to make sure nothing is getting out of hand. It also tells us if the filer has been restarted and how long ago that happened. It gives us a quick view of everything and how much total we're using within Nasuni. This report is something we created on our own to keep track of things.

If a user deletes a file or a file becomes corrupted, it's easy for them to get it restored. There is very little chance that the data is going to be done. We've had a few people delete things, or they have become corrupted, and we were able to get that file back to them in the states that it was in about five minutes before they had a problem. We were able to do this without any issues. Overall, the continuous file versioning is really helpful.

The biggest and most impressive thing for us is the operational recovery (OR) and disaster recovery (DR) capabilities that Nasuni has. If a filer goes down, or an ESX server goes down, then we can quickly recover. For example, we lost a controller the other day and all of the drives were corrupted. We were able to quickly repoint all of the users to a backup filer that we have at our data center, they were back up and running within minutes, and they still have read-write capabilities. Once that ESX server was fixed, we were able to repoint everything back to it in a matter of minutes. People were then again using their local filer to connect.

Nasuni provides continuous file versioning and we take snapshots on a regular basis. Right now, we have them stored forever, but we're trying to reign that in a little bit and keep them only for a period of time. Certainly, at this point, we have a lot of file versions.

We have not had a problem with ransomware but if we did, we would be able to restore the data pretty quickly by going back to an older version of the file before the ransomware took over. It is a similar process to the DR, although a little bit different. For us, OR and DR are pretty much the same thing. We haven't had any disasters that we've had to recover from but we've had three or four hardware failures a year that we've had to deal with. The continuous file versioning has helped to fix these problems pretty quickly.

Continuous file versioning also makes it easier for our operations group. The support team is able to restore files quickly, 24/7, and it is less work for them. They have more time to focus on other problems. The end-user also has access to shadow copies through Windows, and they've used that extensively at the sites.

Nasuni has helped to eliminate our on-premises infrastructure. When we moved to Nasuni, we moved to Azure. Before that, we had a large SAN storage that we were using, and we were able to get rid of it. That was a big difference for us.

We were definitely able to save some money because we've eliminated those expensive SAN disks completely. There were some servers at our old data center that we were able to get rid of, as well. There are some new expenses with Azure because we have to pay for the space taken by the snapshots, which is why we're going to put a retention limit in place. Overall, I don't have an exact number but we were able to save money.

Nasuni is transparent to our end-users. We have it all set up as a file server through Microsoft DFS. If you were to ask one of our end-users how they like Nasuni, they would have no idea what you're talking about.

One issue that we have is related to copying data out of Nasuni. We just sold a site and it was split into two pieces. One part of it was sold to another company and we kept the other part. At the site, they have a Nasuni filer with about eight terabytes of data. Now, we have to split that data and the problem stems from the fact that the other company doesn't have Nasuni.

This means that we have to copy all of that data back to the site and into a format that they can use, which is probably just a Windows file server, and then we have to split it somehow. I'm not really sure that there's an easy way to do that. It's going to take us a little bit longer to separate this other location, and we're having to invent things as we go along.  

In these areas, it's not as simple as it could be, but it doesn't happen very often. As such, we haven't had to worry about it too often. Although it's not affecting us too much at this point, if there's a problem such that we have trouble getting data out of Nasuni, then that could be an issue. However, for the time being, it seems fine.

When we have to rebuild a filer or put a new one at a site, one of the things that I would like to be able to do is just repoint the data from Azure to it. As it is now, you need to copy it using a method like Robocopy. To me, this seems counterintuitive or like we're going backward a little bit. I would like to see a way to be able to switch them around without any problem. That said, I'm not sure if it would then cause other issues because of how Nasuni works, so it may not be possible.

We started using Nasuni in 2018 and it's been running ever since.

Up until about a week ago, the stability has been rock solid. We've actually had a few issues after upgrading to version 9.3 that we're trying to deal with. We have a couple of sites that we're still not sure if Nasuni is the problem, or if it's VMware ESX, and we're working on that. At this point, we're not thinking about rolling back because of all of our sites, only two of them have problems. As such, we think that something else may be going on.

For the most part, it's been extremely stable, with no issues whatsoever. With Nasuni, there has been very little downtime, if any. Most of the sites have never gone down and with the sites that have, there's usually some other external problem.

Overall, it's been very stable for us.

We are limited to the amount of space that we have purchased from Nasuni. If we get close to running out then we just buy more. We still have to pay for the storage within Azure, so we're trying to make sure that it doesn't get out of control. In general, we don't need to add any on demand.

Scalability is not a problem and we can add as many servers and as many filers as we need to, which is really nice. For example, instead of buying tape drives and using that type of backup system, we decided to take a few sites where we have some smaller servers and we use Nasuni to back them up. We use a separate filer to back up all of that data. It's been nice in that way, where we've been able to do things with it that we hadn't originally thought of.

If it should happen that we make a large acquisition, and we bought 10 sites, we could easily put in 10 more filers. It wouldn't be a problem.

Amongst our 35 sites, we have between 10,000 and 12,000 users. A lot of them are office-type people such as those from HR and finance. All of us, including administrators and developers, use it for this kind of thing. The developers wouldn't store code on these because that's not what it's used for. Our Nasuni environment is specifically for data to help the business run, which isn't critical to producing goods or shipping them or anything like that. That is a completely different system. Anybody who works for the company that needs to access simple office data is going to be going through Nasuni.

We have approximately 210 terabytes stored in Nasuni right now. That continues to grow at perhaps a terabyte or two per month. I don't think we'll be moving it anywhere else at this point. Down the road, we do have a very large file system at our data center that we're considering moving, but it's going to take a lot of time to do that one because it's 400 terabytes and it's a lot of old data that we have to clean up first. But that's pretty much the only area that I would see us doing something.

Later this year, we're going to start refreshing some of the hardware because we're approaching five years on some of the older stuff. As we replace it, we'll do another rollout, but it's not going to be like before. We're just going to put a new server in and put a new filer and connect to the data.

Up until recently, I would have rated the technical support a seven out of ten. We had to open a case in Australia for a problem with one of the Nasuni filers, and I haven't got a response for it yet. We had one of the support people answer a question at about three in the morning, US East Coast time, and he said something to the effect that he would send an email giving an update. After that, we didn't hear back from him until about 25 hours later, which was a little concerning for me.

Part of the problem seems to be that Nasuni currently is not set up to do 24/7 support. They said that they were going to do that, so that was a little disappointing. Typically when we call in a problem, they jump all over it and they get it fixed in no time.

From the perspective of our end-users, the servers function the same way when they're working. We had Windows filers before and now they're Nasuni, so it's basically the same thing to them.

Although we mostly used Microsoft, we did use a backup solution called Double-Take, which is now owned by Carbonite. It did the job but it had a lot of idiosyncrasies that were very difficult to deal with at times. That was the only non-Microsoft thing that we used for the data before Nasuni, and we have since stopped using it.

In the beginning, the setup was kind of complex. We did have help from Nasuni, which was great. They were with us the whole time. We had some growing pains at the beginning, but once we figured out the first three or four sites, we were able to get everything done very quickly and efficiently, with very few problems moving to Nasuni.

When we first started with Nasuni, we had never used it before, and we had never used anything like that. We were used to using Windows servers, and there was a learning curve there to figure out the best way to set up the Nasuni filers. We really had to rely a lot on Nasuni for that. Some of it was trial and error, seeing what worked best as we started rolling it out.

We were replacing a single server that was responsible for doing everything. It was a file server, a domain controller, a print server, and an SCCM distribution point. It was all of these different things and we replaced that with one ESX server, which had multiple guest servers on it, doing all those functions separately. It is much better security-wise and much better operationally.

We started with a very slow implementation. We implemented one site, and then we waited two months before moving to the second site. We tried to start with some of the smaller sites first, with the least amount of data, to get our feet wet. Also, the first site we did was the one that I sit at. The team was all there and it was our site, so we figured we should do our site first. We staggered deployment, so it was not very quick. Then, once we had three or four completed, we did three a week for three months and we were done.

After completing the first site, choosing the next sites had to do with the hardware. We had some old hardware that we repurposed, so we did those sites next. After that, we moved to the sites that necessitated purchasing new hardware. 

From beginning to end, our implementation took a little more than a year. It began in August of 2018 and finished at the end of Q3 in 2019. The time it took was not because of Nasuni. Rather, it revolved around different ordering cycles in our company. Buying the new hardware was what stretched out the deployment time.

I was in charge of the team that did the implementation.

For purchasing and the initial negotiations with Nasuni, we used CDW. We still interact with them when it's time to do renewals, and they are great to deal with. They really help out quite a bit. They were the ones that brought us Nasuni in the first place and suggested that we take a look at it.

We're very happy with CDW. We use them for all of our hardware orders, and a couple of different infrastructure tools. We use them quite extensively.

We had four people responsible for the deployments, with one guy who was in charge of the group as the lead architect. Once it was deployed, we turned it over to our operations group, which is outsourced to TCS. Although they have supported us since then, they come to us if there's anything that's still an issue. We have a couple of guys that still work with Nasuni a little bit, but that's basically how the maintenance is done.

For the most part, there is little maintenance to do. There are situations such as when a controller card goes down, or like the issues we have been having since the upgrade. Otherwise, it's very hands-off and you really don't have to do a lot.

We don't plan on calculating a return on investment with this solution. In the grand scheme of things, it's really not very much money for what we're doing. We spend more money on the hardware, for example.

Our agreement is set up such that we pay annually per terabyte, and we buy a chunk of it at a time. Then if we run out of space, we go back to them and buy another chunk.

We thought about an agreement with a three-year plan, where we would get a small increase every year, but we decided not to take that approach at this time. We go through CDW for these agreements and they help us get all of the quotes together.

In addition to what we pay Nasuni, there is the cost of storage in Azure or whatever cloud service you're using. It can get pretty pricey if you have a lot of snapshots, which is something we've found and we're now trying to scale back on. That's the biggest thing that is extra and you may not think of right at the beginning.

We looked at a few different products that year, and we decided that Nasuni was the best way to go. It has really worked well for us.

One of the products that we looked at was Veeam, the backup software, but it would have been used a little bit differently. We also looked at Backup Exec and a tool from Microsoft. We didn't look at anything that was exactly like Nasuni. We looked at these other things that would create backups of the primary data, which would have stayed at the site. Nasuni was a completely different way of looking at it.

The difference with Nasuni is that rather than having a backup in the cloud, the primary copy of the data is what's in the cloud. For us, it's stored in Azure, whereas with the other tools, the primary copy stays at the site. If you had a major problem, for instance, this issue with the controller card, the problem with these other solutions or the way it was before was that you're down and out at least until you can get the controller card replaced.

Then, once you're back up, you're going to have to copy all of the data back. For that, it would probably need at least a week. Some of these sites have very poor connections. For example, we have a site that's in the Amazon jungle in Brazil and they are notorious for being very slow, yet we've used Nasuni there and it works fine. Some of these other solutions probably wouldn't have worked. In fact, we probably would have had to buy a tape drive and back up the servers that way.

We have a hosted data center where we don't pay for individual items, such as servers. Instead, we pay for a service. The service might include a server or storage, and Nasuni has not eliminated that because we still need our physical servers at the locations. We debated on whether or not to put the filer in Azure for each site, but we decided that it was better to have something local at this point.

For our company, we were a little ahead of the curve. We didn't have internet connections directly from each site, and they all routed through a central internet connection. Because of that, it was difficult to eliminate any hardware at the site. We needed something there physically. But, having the virtual appliance for Nasuni really helps out quite a bit, because then we only have to have one piece of hardware and we can put all of the other servers that we need for infrastructure on the same ESX server. We have five or six different servers that are doing different functions that at one point, would maybe have been three or four different physical servers. Now we've reduced it to one.

We use Microsoft SCOM as a monitoring tool to keep track of all of the filers and make sure that they are running. 

We don't use the Nasuni dashboard because we don't have to. Everything is working the way it is. We do have a management console set up and we do go into that occasionally, but it's not something that's a regular thing that our support people use.

If I had a colleague at another company with concerns about migration to the cloud and Nasuni's performance, I would talk about the fact that the OR capabilities are so different than anything else that I've seen. The performance has actually not been too bad. You would think that there would be an issue with the cloud stores, but we set up a local cache on each filer that allows it to store up to a terabyte or two of regularly used data. That gets probably 80% of what people use, which means that they're accessing a local copy that's synced with what's in the cloud. This means that they don't really have to go to the cloud to get a lot of it. But when they do, it's pretty quick. It may not be as fast as if it were a local copy, but it's not too bad.

My advice for anybody who is considering Nasuni is that they definitely want to look at all of the options, but that Nasuni does have the best setup at this point. It offers the ability to recover things and provides data security. Especially with ransomware and all of these other new things that are causing lots of problems out there, it really helps mitigate some of that.

The biggest thing that I have learned from using Nasuni is that you shouldn't be afraid of the cloud.

I would rate this solution an eight out of ten.

Originally, I was looking for a solution that allowed us to replicate our critical workloads to a cloud target and then pay a monthly fee to have it stored there. Then, if some kind of disaster happened, we would have the ability to instantiate or spin up those workloads in a cloud environment and provide access to our applications. That was the ask of the platform.

We are a manufacturing company, so our environment wouldn't be drastically affected by a webpage outage. However, depending on the applications that are affected, being a $15 billion dollar company, there could be a significant impact.

Zerto is very good in terms of providing continuous data protection. Now bear in mind the ability to do this in the cloud is newer to them than what they've always done traditionally on-premises. Along the way, there are some challenges when working with a cloud provider and having the connectivity methodology to replicate the VMs from on-premises to Azure, through the Zerto interface, and make sure that there's a healthy copy of Zerto in the cloud. For that mechanism, we spent several months working with Zerto, getting it dialed in to support what we needed to do. Otherwise, all of the other stuff that they've been known to do has worked flawlessly.

The interface is easy to use, although configuring the environment, and the infrastructure around it, wasn't so clear. The interface and its dashboard are very good and very nice to use. The interface is very telling in that it provides a lot of the telemetry that you need to validate that your backup is healthy, that it's current, and that it's recoverable.

A good example of how Zerto has improved the way our organization functions is that it has allowed us to decommission repurposed hardware that we were using to do the same type of DR activity. In the past, we would take old hardware and repurpose it as DR hardware, but along with that you have to have the administration expertise, and you have to worry about third-party support on that old hardware. It inevitably ends up breaking down or having problems, and by taking that out of the equation, with all of the DR going to the cloud, all that responsibility is now that of the cloud provider. It frees up our staff who had to babysit the old hardware. I think that, in and of itself, is enough reason to use Zerto.

We've determined that the ability to spin up workloads in Azure is the fastest that we've ever seen because it sits as a pre-converted VM. The speed to convert it and the speed to bring it back on-premises is compelling. It's faster than the other ways that we've tried or used in the past. On top of that, they employ their own compression and deduplication in terms of replicating to a target. As such, the whole capability is much more efficient than doing it the way we were doing it with Rubrik.

If we lost our data center and had to recover it, Zerto would save us a great deal of time. In our testing, we have found that recovering the entire data center would be completed within a day. In the past, it was going to take us close to a month. 

Using Zerto does not mean that we can reduce the number of people involved in a failover.  You still need to have expertise with VMware, Zerto, and Azure. It may not need to be as in-depth, and it's not as complicated as some other platforms might be. The person may not have to be such an expert because the platform is intuitive enough that somebody of that level can administer it. Ultimately, you still need a human body to do it.

The most valuable feature is the speed at which it can instantiate VMs. When I was doing the same thing with Rubrik, if I had 30 VMs on Azure and I wanted to bring them up live, it would take perhaps 24 hours. Having 1,000 VMs to do, it would be very time-consuming. With Zerto, I can bring up almost 1,000 VMs in an hour. This is what I really liked about Zerto, although it can do a lot of other things, as well.

The deduplication capabilities are good.

The onset of configuring an environment in the cloud is difficult and could be easier to do. When it's on-premises, it's a little bit easier because it's more of a controlled environment. It's a Windows operating system on a server and no matter what server you have, it's the same.

However, when you are putting it on AWS, that's a different procedure than installing it on Azure, which is a different procedure than installing it on GCP, if they even support it. I'm not sure that they do. In any event, they could do a better job in how to build that out, in terms of getting the product configured in a cloud environment.

There are some other things they can employ, in terms of the setup of the environment, that would make things a little less challenging. For example, you may need to have an Azure expert on the phone because you require some middleware expertise. This is something that Zerto knew about but maybe could have done a better job of implementing it in their product.

Their long-term retention product has room for improvement, although that is something that they are currently working on.

We have been with Zerto for approximately 10 years. We were probably one of the first adopters on the platform.

With respect to stability, on-premises, it's been so many years of having it there that it's baked in. It is stable, for sure. The cloud-based deployment is getting there. It's strong enough in terms of the uptime or resilience that we feel confident about getting behind a solution like this.

It is important to consider that any issues with instability could be related to other dependencies, like Azure or network connectivity or our on-premises environment. When you have a hybrid environment between on-premises and the cloud, it's never going to be as stable as a purely on-premises or purely cloud-based deployment. There are always going to be complications.

This is a scalable product. We tested scalability starting with 10 VMs and went right up to 100, and there was no difference. We are an SMB, on the larger side, so I wouldn't know what would happen if you tried to run it with 50,000 VMs. However, in an SMB-sized environment, it can definitely handle or scale to what we do, without any problems.

This is a global solution for us and there's a potential that usage will increase. Right now, it is protecting all of our criticals but not everything. What I mean is that some VMs in a DR scenario would not need to be spun up right away. Some could be done a month later and those particular ones would just fall into our normal recovery process from our backup. 

The backup side is what we're waiting on, or relying on, in terms of the next ask from Zerto. Barring that, we could literally use any other backup solution along with Zerto. I'm perfectly fine doing that but I think it would be nice to use Zerto's backup solution in conjunction with their DR, just because of the integration between the two.  

In general, the support is pretty good. They were just acquired by HP, and I'm not sure if that's going to make things better or worse. I've had experiences on both sides, but I think overall their support's been very good.

Zerto has not yet replaced any of our legacy backup products but it has replaced our DR solution. Prior to Zerto, we were using Rubrik as our DR solution. We switched to Zerto and it was a much better solution to accommodate what we wanted to do. The reason we switched had to do with support for VMware.

When we were using Rubrik, one of the problems we had was that if I instantiated the VM on Azure, it's running as an Azure VM, not as a VMware VM. This meant that if I needed to bring it back on-premises from Azure, I needed to convert it back to a VMware VM. It was running as a Hyper-V VM in Azure, but I needed an ESX version or a VMware version. At the time, Rubrik did not have a method to convert it back, so this left us stuck.

There are not a lot of other DR solutions like this on the market. There is Site Recovery Manager from VMware, and there is Zerto. After so many years of using it, I find that it is a very mature platform and I consider it easy to use. 

The initial setup is complex. It may be partly due to our understanding of Azure, which I would not put at an expert level. I would rate our skill at Azure between a neophyte and the mid-range in terms of understanding the connectivity points with it. In addition to that, we had to deal with a cloud service provider.

Essentially, we had to change things around, and I would not say that it was easy. It was difficult and definitely needed a third party to help get the product stood up.

Our deployment was completed within a couple of months of ending the PoC. Our PoC lasted between 30 and 60 days, over which time we were able to validate it. It took another 60 days to get it up and running after we got the green light to purchase it.

We're a multisite location, so the implementation strategy started with getting it baked at our corporate location and validating it. Then, build out an Azure footprint globally and then extend the product into those environments. 

We used a company called Insight to assist us with implementation. We had a previous history with one of their engineers, from previous work that we had done. We felt that he would be a good person to walk us through the implementation of Zerto. That, coupled with the fact that Zerto engineers were working with us as well. We had a mix of people supporting the project.

We have an infrastructure architect who's heading the project. He validates the environment, builds it out with the business partners and the vendor, helps figure out how it should be operationalized, configure it, and then it gets passed to our data protection group who has admins that will basically administrate the platform and it maintains itself.

Once the deployment is complete, maintaining the solution is a half-person effort. There are admins who have a background in data protection, backup products, as well as virtualization and understanding of VMware. A typical infrastructure administrator is capable of administering the platform.

Zerto has very much saved us money by enabling us to do DR in the cloud, rather than in our physical data center. To do what we want to do and have that same type of hardware, to be able to stand up on it and have that hardware at the ready with support and maintenance, would be huge compared to what I'm doing.

By the way, we are doing what is considered a poor man's DR. I'm not saying that I'm poor, but that's the term I place on it because most people have a replica of their hardware in another environment. One needs to pay for those hardware costs, even though it's not doing anything other than sitting there, just in case. Using Zerto, I don't have to pay for that hardware in the cloud.

All I pay for is storage, and that's much less than what the hardware cost would be. To run that environment with everything on there, just sitting, would cost a factor of ten to one.

I would use this ratio with that because the storage that it replicates to is not the fastest. There's no VMs, there's no compute or memory associated with replicating this, so all I'm paying for is the storage.

So in one case, I'm paying only for storage, and in the other case, I have to pay for storage and for hardware, compute, and connectivity. If you add all that up into what storage would be, I think it would be that storage is inexpensive, but compute added up with maintenance and everything, and networking connectivity between there and the soft costs and man-hours to support that environment, just to have it ready, I would say ten to one is probably a fair assessment.

When it comes to DR, there is no real return on investment. The return comes in the form of risk mitigation. If the question is whether I think that I spent the least amount of money to provide a resilient environment then I would answer yes. Without question.

If you are an IT person and you think that DR is too expensive then the cloud option from Zerto is good because anyone can afford to use it, as far as getting one or two of their criticals protected. The real value of the product is that if you didn't have any DR strategy, because you thought you couldn't afford it, you can at least have some form of DR, including your most critical apps up and running to support the business.

A lot of IT people roll the dice and they take chances that that day will never come. This way, they can save money. My advice is to look at the competition out there, such as VMware Site Recovery, and like anything else, try to leverage the best price you can.

There are no costs in addition to the standard licensing fees for the product itself. However, for the environment that it resides in, there certainly are. With Azure, for example, there are several additional costs including connectivity, storage, and the VPN. These ancillary costs are not trivial and you definitely have to spend some time understanding what they are and try to control them.

I looked at several solutions during the evaluation period. When Zerto came to the table, it was very good at doing backup. The other products could arguably instantiate and do the DR but they couldn't do everything that Zerto has been doing. Specifically, Zerto was handling that bubbling of the environment to be able to test it and ensure that there is no cross-contamination. That added feature, on top of the fact that it can do it so much faster than what Rubrik could, was the compelling reason why we looked there.

Along the way, I looked at Cohesity and Veeam and a few other vendors, but they didn't have an elegant solution or an elegant way of doing what I wanted to do, which is sending copies to an expensive cloud storage target, and then having the mechanism to instantiate them. The mechanism wasn't as elegant with some of those vendors.

We initially started with the on-premises version, where we replicated our global DR from the US to Taiwan. Zerto recently came out with a cloud-based, enterprise variant that gives you the ability to use it on-premises or in the cloud. With this, we've migrated our licenses to a cloud-based strategy for disaster recovery.

We are in the middle of evaluating their long-term retention, or long-term backup solution. It's very new to us. In the same way that Veeam, and Rubrik, and others were trying to get into Zerto's business, Zerto's now trying to get into their business as far as the backup solution.

I think it's much easier to do backup than what Zerto does for DR, so I don't think it will be very difficult for them to do table stakes back up, which is file retention for multiple targets, and that kind of thing.

Right now, I would say they're probably at the 70% mark as far as what I consider to be a success, but each version they release gets closer and closer to being a certifiable, good backup solution.

We have not had to recover our data after a ransomware attack but if our whole environment was encrypted, we have several ways to recover it. Zerto is the last resort for us but if we ever have to do that, I know that we can recover our environment in hours instead of days.

If that day ever occurs, which would be a very bad day if we had to recover at that level, then Zerto will be very helpful. We've done recoveries in the past where the on-premises restore was not healthy, and we've been able to recover them very fast. It isn't the onesie twosies that are compelling in terms of recovery because most vendors can provide that. It's the sheer volume of being able to restore so many at once that's the compelling factor for Zerto.

My advice for anybody who is implementing Zerto is to get a good cloud architect. Spend the time to build out your design, including your IP scheme, to support the feature sets and capabilities of the product. That is where the work needs to be done, more so than the Zerto products themselves. Zerto is pretty simple to get up and running but it's all the work ahead in the deployment or delivery that needs to be done. A good architect or cloud person will help with this.

The biggest lesson that I have learned from using Zerto is that it requires good planning but at the end of it, you'll have a reasonable disaster recovery solution. If you don't currently have one then this is certainly something that you should consider.

I would rate Zerto a ten out of ten.

This is our main backup system. All of our VMs, our hardware hosts; everything is backed up using Rubrik.

Disaster recovery is one of the options we have explored, so that in case of a big disaster we could utilize their image conversion to run our VMs on AWS, but that is just a proof of concept at this stage. We have tested it. It works. But we don't have a proper plan in place for that.

We have only one physical server that we are protecting with it and the rest are all virtual servers. We have around 400 server VMs and all of them are protected using Rubrik. Most of our environment, around 90 percent, is VMware, while 10 percent of our environment is Hyper-V. 

With the VMs we are also taking backups of our CIFS shares. We have our file clusters running Windows Servers so we are taking backups using the SMB mount. We have NFS clusters as well, for the Linux side, which we're backing up using the built-in NFS connectors. We explored SQL backups, but right now we are using our SQL Server to dump the data and then the files are being backed up. We're not directly backing up SQL using Rubrik.

The SLA-based policy automation has had a very good effect on our data protection operations. We came from Commvault and we used to have tape backups. It was a full-time job for one of our sys admins to update the tape library, replace the tape cartridges, recycle them, scratch them, and then bring them back. It was a huge process. We were using offsite storage to store our tape backups which were continuously going back and forth from our campus. Now it's all automated. We barely have to manage anything. We are now consumers instead of actually setting this up. It was one set up and we just maintain it now.

It saves us time when it comes to managing backups because we barely do anything, other than just verify. We get a daily report to see if any of the VMs are out of our SLA. The only action item we have, if something is out of SLA, is to verify what happened, why the backup failed or missed its window. Given that it was tape before, it has gone from hours to minutes. It used to be more proactive, where we were continuously checking everything and replacing the tapes and making sure that everything went through. Now, it's more of a reactive situation, where we only look at a backup when there is an issue.

It has also definitely reduced the time we spend on recovery testing, because it can do Live Mounts and that does not require an actual recovery. So our VMs are instantly available. And the file restore feature allows us to explore the file system of every VM, instead of restoring it, and then just restore the files that we need, and that has been amazing so far as well. Within a few minutes, we have either the VM or the files available. I don't even know how to compare it to Commvault and the tape backups. When I joined Harvard, they already were on Rubrik and we were decommissioning Commvault, so I know a little bit about the process. We do classroom recordings in Harvard Law School and those were still going to Commvault. That was the last project that I was involved in and I saw the crazy amount of work involved where we had to bring all the tape libraries from safe.

And when it comes to recovery time itself, it's an instant recovery in most circumstances, even if we have to recover something that's more than three days old. In our environment, after something is more than three days old it goes to an archival location on S3. When we restore data that is between three and 42 days old it is downloaded from S3 and then made available. For us, that situation is a little bit slower compared to the Live Mount. Depending on the size of the VM, it could range between a few minutes to a few hours. But if the data is on premises, it downloads the data instantly.

We don't have to worry about the solution too much, which definitely has helped our productivity. Most of our workflow is automated, where VMs are automatically added. The SLA is automatically assigned. Things are automatically archived. Anyone can take action. We have on-call people who look at the reports and take action as needed.

There is a live-restore feature, their Live Mount, and the way it works we can instantly recover a VM, a past backup, to be directly attached to our VMware environment. Rubrik will act as a disk for it. It's like an instant restore. Within a few minutes our VM is up and running. And then, if we want to restore it, we can just migrate it to our actual storage.

Rubrik's web interface is very simple to use. We have a very simple SLA configured so that everything is backed up every day. Any new VMs we configure in our environment automatically get added, the SLA is automatically assigned to them. All the VMs, after three days, are archived to AWS S3, and then there's a life cycle on the AWS side to work with that.

The archival functionality is one of the main features because the Rubrik that we have has about 60 or 70 TB of total local storage, which is definitely not enough for our data. We have around 140 TB of data stored on AWS and, without the archival feature, we would have to buy at least three times the number of nodes that we currently have to keep all the data secure for 42 days, based on our SLA. It's definitely saving us on costs. It also gets us away from having to keep redundancy on the data, because if we were storing it on-premises we would have to make sure that we have redundancy and offsite storage. Now, all of that is AWS. We no longer have to worry about that.

Capacity reports could definitely be improved. It's hard to determine what is using the space and why. For instance, you can see that some host is using 2 TB on the Rubrik node and the disk space on that host is 400 GBs. It's hard to explain how there can be 2 TBs of data on local storage when nothing has changed on the host for the past three days. 

They have improved a lot on the SLA reports. We used to get a lot of false alerts before, because a snapshot was missed. In the reports it would remain a "non-compliant to an SLA for 42 days, until the 42 cycles were done. They've removed that. If it misses an SLA and if you take another snapshot or to take an automatic backup, it automatically fixes the SLA report to show us it's protected.

Most of their documentation for cloud stuff can be improved. This could be old information, as we did the PoC last year and maybe their documentation has been updated now, but we literally had to contact support every day, and at every step for things like, "Okay, what do we do with the AMIs? How do we get Rubrik configured? How do we convert the image?" None of that was available in a single documentation format. It was spread around in different documentation.

I've been using Rubrik for the past three years, since I joined Harvard, but I think it was deployed on-premises four or five years back.

It's very stable. We have had an instance where one of the nodes was offline for no reason, but working with their support it was determined that there was a cache issue and they fixed it.

We don't have to worry about backups. We have been using it for more than four years and so far there hasn't been a single incident where we have had any issues recovering any of the files or VMs. It is very robust, continuously updating.

They have everything available by API, which is a good thing because this is the way that things are going forward with an API-first infrastructure. In terms of their physical nodes you can also scale them, but there's a requirement of always increasing in sets of three more nodes. We have one Brik and four nodes currently, and to increase our storage we would have to buy three more nodes, which is kind of a limitation. It would have been nice if we could just buy one node and increase that way, gradually, instead of buying three large nodes. But I can't complain about it. That's probably their infrastructure.

We are using it for everything except our media storage. Our classroom recordings are directly archived to glacier and everything else goes through Rubrik. The reason for that is that we don't want on-premises storage of the media. These are large video recordings and it would be very expensive to store them locally. Rubrik keeps a local copy for three days, for regular backups. We are actually testing a new feature where you can connect to NAS storage and there will be no local data, only metadata, stored locally. Everything else is archived. We have tested this feature with their support. They showed it to us but we haven't acquired the license to start using it yet.

Only sys admins have access to Rubrik in our organization. Currently, 10 of our sys admins have access to the system. 

Rubrik support is amazing. When we are involved in upgrades we always open a ticket and there is a tech person joined through a tunnel and looking at the upgrade while it's being done. It's like everything is off our shoulders in terms of managing it. If something goes wrong, they're always available to support us.

Every time we've opened a ticket with them, even to explore new features, we have always gotten an instant response, and even when it comes to trial licenses. The whole proof of concept project we did on AWS for DR was provided from their support, and it has been amazing. The experience has been really good.

Most of the time, their turnaround time for tickets is less than 24 hours, especially with high-priority tickets. Recently, we have had some issues with our VM storage sizes not reflected properly. We were looking at a capacity report and we were seeing some of the VMs using way more storage on Rubrik than they should. This has been a difficult problem and they have continued to escalate it to different engineers. That is the longest interaction we have had and the issue is still pending.

We are not running the bleeding edge, so there is a possibility that if we do switch to 5.2 we might see an improvement already on that deduplication; that might be the reason that this is happening. They are looking into it. They have suggested a couple of actions from our end to actually delete those backups, archive them, and restart the backups, but they're still looking into it.

We wanted to get away from tapes. We tried Veeam but it did not work very well for us. There were a couple of shortcomings which we couldn't maintain, plus it wasn't cloud-ready at that moment, at least not to the extent that Rubrik was.

Rubrik was very fresh in the market at that time, but it was bringing features that we were looking for. We were already set on using either Azure or AWS and it had the needed support for them.

I've been involved with upgrades but not an install because we just have the one on-premise device. I've been involved in multiple proofs of concepts. For example, they launched a couple of features along the way where we were testing cloud workloads and converting our images to native AWS images so that we could use it as a disaster recovery site in the future, if needed. All of our backups are going to AWS.

Upgrades are very straightforward. Their support is always with us, so we haven't had any hiccups during the upgrades. They go very smoothly. I've been involved in multiple upgrades, and we were at some point running the bleeding edge software, when we were looking for some features that were available, without any issues. So we did upgrade to the latest and greatest version. Our general policy is to stay one version behind to iron out all the bugs. But with Rubrik we have attempted to run the latest version, to use the features, and it has been stable enough for us and the upgrades have gone smoothly.

We usually block out a two-hour maintenance window for upgrades. There have been major upgrades which required some database work, and they have taken more time. In the move from version 4 to version 5 their whole database infrastructure was changed.

We got grandfathered in the licensing terms. Their licensing is much more narrow now and you have to buy licenses for every cloud feature, but we got most of those things as a package.

We got really good pricing because we're in the education sector and we were one of the first big organizations to start using Rubrik.

Recently, when we were looking for direct backup to glacier, we started using CloudBerry which is a very basic product. It's a standalone install on our media servers and it's directly backing up to glacier. It's a single unit license on the single server; there's no hardware involved with it.

The only advantage of CloudBerry is that we're not keeping an on-premises copy. When we take a backup with Rubrik it creates an on-premises copy of all of our media files and then uploads them, and that requires more storage on Briks that we don't want to spend money on. The Rubrik feature we tested, where you connect to NAS storage, wasn't available when we acquired the license from CloudBerry.

Rubrik is an amazing product. There are some features still missing. For example, you cannot do a granular backup or restore of Active Directory. That has been on my wish list. I have posted that on their tech forum where people discuss new features and new things that they are launching. I know that it will come because they have been adding other granular backup support with VSS. The AD-level granular backup, so we can restore a single account or a single computer, is the one of the last features that we are requesting. They usually do bring out whatever features we request in their next update.

We have not used the solution's ransomware recovery. I have attended a couple of seminars where they have recently been talking about that, but we haven't tested it. We haven't had any incidents which would require us to use that feature.

We have also not used its pre-built integrations or API support for integrations with other solutions. We played with a couple of features, such as the organization features to segregate some of our VMs, but we found that it was not possible the way we handle the system. We wanted to make our domain controller backups inaccessible to our backup administrators, because we wanted that to be part of the DCA job. So we explored the organizations, but the way it works we would have had to move everything into an organization and our backup administrators were taking care of everything except domain controllers. So we dropped the idea of using organizations.

In terms of downtime, I don't think Rubrik has reduced that in a meaningful way. We have a pretty redundant environment anyway. If something happens to our VMware hosts, the VMs automatically fail over to other hosts so there is rarely any downtime. We have been off physical servers for quite some time. If there were physical servers, Rubrik could help reduce downtime, but since we don't have physical servers we don't even know what the recovery would look like with Rubrik. With tapes it was crazy when something happened. If someone did not look at RAID and we had a two-drive failure or a three-drive failure, then it would be a full recovery from tape. But now, because everything is running on VMs, we have no downtime, most of the time.

Overall the product is really good. Rubrik is very competitive. Even if you now look at their positioning on the industry review sites, they are doing really well. It's a very good product. We recommended the product to our Central IT department. We are Harvard Law School, but Harvard has a Central IT which manages other schools, and they are doing a PoC right now. It's a good product to recommend.