Quest Rapid Recovery Reviews

We use it to back up all of our data. The only servers that I do not have on here are my VoIP servers. I have a SQL database. I have an ERP server. I've also got a couple of file servers and a couple of domain controllers. I also back up my Hyper-V host machines. So, pretty much everything that we have is backed up here.

We are on the latest version, which is 660268.

It has reduced our admin time by approximately 95%. In the previous backup utility that we used, we were basically manually running a command every night to copy and paste anything that had a newer date than the previous day. On top of the fact that we had to manually launch that every night, we also had to make sure that we covered every drive that was going to be involved for that particular night's changes. Now, I can add servers and just plug them in there. Everything is already pre-configured, so I just add the machine.

Previously, we were using a tape backup. As our quantity of data expanded, when we would do the backup process at night, it was quite cumbersome, and very often, it would extend into the better part of the next day. If someone realized at 9:00 that there is a file that got corrupted or was deleted, they would notify me, and I would tell them that I will restore that, but I have to wait until the last night's job completes. After the job is complete, I had to go back and find the tape that had the copy of what they were looking for. Very often, that person would be waiting until the end of that day before they could resume whatever tasks they were trying to do, whereas now, it doesn't matter what's going on, on the Rapid Recovery side. My backups occur every hour, and it takes a snapshot. In a worst-case scenario, they may have to go back and repeat whatever they lost in that hour's time, but I can restore files for them almost immediately, and they can get right back to it. It has made a huge difference in that regard because previously, sometimes, they had to wait the entire day before I could get in and actually restore with the tape that had the data that they were missing.

It enables us to recover complete systems, applications, and data with little to no disruption to the work environment. I personally have not had to do that, but my counterpart has had to recover an entire server. He lost his exchange server at one point, and although, it did take him a couple of hours to get everything back up and running efficiently, he was able to back it up to the last good backup. Within an hour or two, he was able to get everything back up and running for users without a whole lot of data loss.

I use incremental backups daily. When I first bring a brand new machine, I take a base image, and then every subsequent backup going forward is incremental. The full base images are obviously redundant, and they fill up your repository quite quickly. Prior to adding additional storage, we didn't have a whole lot of wiggle room. We just didn't have the space to take another entire snapshot of the data. Incremental backups kind of do the dedupe and keep everything at the most efficient level of data so that you have everything you need, but you don't have a lot of fluff in there. You don't have extra copies of the same thing that you can grab from four different backup files. It is there, deduped. You just have your one pristine copy, which helps keep your storage really streamlined so that you're only using what you need versus a lot of excesses.

Incremental backups have reduced storage costs. We have roughly about 7 terabytes of storage, and while storage is not extremely expensive these days, it still adds up. So, if I were needing to have multiple copies of 7 terabytes at a time, it will cost you serious coin to have enough devices to hold that much in addition to buying licensing for that much. If all of your data sits in 7 terabytes, why would you want to pay licensing for 10 terabytes? That just doesn't make good business sense.

Incremental backups help to reduce the impact of our production environment or network resources. We replicate over the WAN. While we do have adequate bandwidth, if we were having to replicate base images consistently, it is obviously going to be pulling some of our resources for replication, whereas the incremental backups really replicate in a matter of minutes. We might have a couple of minutes here and a couple of minutes there when a replication job is happening, but they're pretty seamless. I don't know if anyone even notices. If we were replicating, it would be a consistent drain on our bandwidth until that huge file is replicated. So, incremental backups just keep everything running smoothly, quickly, and efficiently.

It affects the peace of mind when it comes to knowing our backups are completing. I do get an email if ever, for one reason or another, a job is not running. I typically reboot all of my servers over the weekend, and on one of my servers, when the agent did not start for any reason, I received an email that said that this job was missed because the agent is offline. So, I logged in and manually started it. There was no issue, and everything was up and running again. Similarly, my SQL backups will email me and tell me that the logs are truncated. No news is good news, but I know that if there is a blip of any sort, I'm going to get a notification email alerting me to take a look so that I can nip it in the bud right away. It is reassuring to have this communication.

It has been our experience quite often that files get deleted, but you do not notice that for a very long period of time. So, if something is deleted and no one caught it for six months, it's extremely important to know that you are going to be able to still recover that data.

We're kind of restructuring things, so we're not doing it currently, but we have another business that is owned by the same owners. They also use Rapid Recovery, but they are about four miles from here. We replicate. So, we have a copy on DL4000, and then we also have a copy on a SAN. We then replicate across the WAN to a core in their location, so we've got multiple copies. Primarily, we've started thinking about worst-case scenario disasters. Even though we have DL4000 and we have the raw data on a SAN, but in case a tornado goes through and wipes out our building, both copies would up in the clouds. So, we started doing replication across the WAN. Once you get the original configuration set up, it is pretty much set it and forget it. I do look at it every day and check for errors and the likes of that, but for the most part, it is pretty self-supporting. It doesn't require a whole lot of administration, which is really beneficial because you have enough other things going on throughout the day. You don't have to babysit it all the time.

It includes deduplication, replication, and virtual standby without having to pay extra. From a storage standpoint, the dedupe was important because we did not want to run into a situation where the data size was growing exponentially. In terms of replication, we wanted to be able to ensure that we had multiple copies in the event of a disaster. We wanted to make sure that we had a game plan for the worst-case scenario, and that it was something that we can trust and would fit the bill if we were facing that kind of scenario. We feel confident that it would do what it says it's going to do. We, fortunately, didn't have to rely on virtual standby. However, one of my counterparts in another sector of our business has used it, and it has worked out very well for him. Just seeing his experience and knowing that if we were facing a similar dilemma, it would work is immeasurable.

We deploy it to all of our servers and we take all of the hard drive images and backups of the servers themselves.

Our primary use case is to replicate all our server data. We still may end up adding more licenses, but we've done our core file and print servers that we would really need that are crucial to the company.

We are actually in the process of purchasing VMware vCenter licenses. So, we have the paid version of VMware vCenter and we're going to be doing offline backups of the virtual machines themselves through VMware. We're going to use Quest as the data solution.

Our company survived a ransomware attack and the repository was not encrypted by the Conti ransomware strain.

It enables us to recover complete systems, applications, and data with little or no disruption to the work environment. Obviously, there's going to be some downtime on our domain when we're recovering an entire server, but we do use the features of doing the complete systems because all of our servers now are virtual machines, we're able to do complete restores of the virtual machine from Quest, which is important.

Quest's synthetic incremental backups are nice. The fact that it spreads it out a little bit and gives us more backups of the data itself is good. It allows us to go further back in time. I like the incremental backups because it doesn't take up as much space and it gives us a chance to go further back if we need to.

We have reduced the storage cost using synthetic incremental backups to a certain extent. The new server that we've set up for Quest, we extended the drives on it, so, it's allowed us to go a little bit further back. But our stuff's been mostly around eight to 10 terabytes and with incremental is about a month back.

It runs on its own separate server and it just runs in the background twice a day, noon and midnight. It works well and no one really notices.

We have peace of mind knowing that our stuff's being backed up and that there are no issues with it. Knowing that I can, from a protection standpoint, protect our users' data efficiently and can recover their data if need be from a month back, is very important.

Restoring a failed server from backup or failover to a virtual standby depends on the size, but if it's one of our bigger ones, would take anywhere from an hour to two or three hours. It just depends on how big of a server it is.

It's one of those things where we'll be temporarily down, but knowing that we're going to be back up in a pretty quick period once that restores complete is nice and helped us get back on our feet.

It is basically used for everything. It is used all the way from files recovery on a simple basis, where one user accidentally deletes a file and we need to replace it, to a server crash, where we need to bring it up virtually on another unit because the hardware crashed or something like that.

It is deployed on-prem. We have two units with Rapid Recovery. So, we have two DL1300s. It was sold as an appliance package at the time.

Previously, in order to do a restore on a file, you had to go through and find the file on a tape or whatever your medium is. You had to go through and dig until you found it, which used to take forever, whereas now, you can mount the whole server in a few minutes, and you can go down and dig into the file you're looking for. If it is not in that directory, all your other directories are available. Doing it this way saves you a lot of time versus the old way, where you find that one file and restore it. If that doesn't turn out to be the file that the user wanted, you got to go back and do it all over again for the other file that they have guessed as being the one. It saves you a lot of time because you're mounting the whole server to a point in time, and then you can grab any file from that point in time and then give it to the user. You can copy/paste it or use some other preferred way. So, it is very easy to use, and it saves hours on each restore.

We spin up all of our machines as virtual machines. They have a feature called virtual standby that allows you to keep all of your virtual machines in a state where they're basically standby virtual machines. All you have to do is spin them up, and then that machine is up and running. So, we test that functionality quarterly to make sure that it is working. We need to know the backups are working. Otherwise, we get alerts if they're not working. The backups go between every hour, every four hours, and every 24 hours. In terms of doing recovery, once every couple of months, we have to recover a file or do something similar. This virtual standby feature would save us quite a bit of time if we have to recover specific servers that have crashed and bring them up with Rapid Recovery. It would save us approximately four to eight hours.

Our primary use is backup and restore, which we use to protect our customers' data centers.

From an operations standpoint, the email notifications have helped me a lot.

The mount function has helped us because it is a straightforward process that we can explain to a customer over the phone. When they need to restore a file or a folder, there are only a few steps involved.

Many times, we have been able to recover data with little disruption to our customer's work environment. In a few cases, it helped me to recover all of the data for a customer, which was a big help.

In cases where we have had to restore a failed server, the process has been quite fast. The timeframe depends on the size of the data but it is faster than other products we have worked with.

There are multiple choices for restoring data. For example, first, you can create a virtual standby, and then restore data while it is being used. Alternatively, you can bring up another server and then restore data to it. I have not yet used virtual standby in production.

It is for any kind of company that uses their own servers.

From a global perspective, our clients are small-sized companies. All the SMEs, compared to the Slovakian market, are quite small. It's a small market with small companies. They just want to enhance security and follow regulations.

It's the speed. Granular recovery, and also the possibility to connect all different Quest products together. So it works like Lego blocks.

Replication is good. The data protection strategy varies on a case-by-case basis, but overall, it's doing well. The customers who use Quest are still satisfied.

We are primarily using the solution for backing up our critical servers and certain SQL servers.

Rapid Recovery comes with internal rapid recovery. We can make a backup for critical machines on a disk outside of our data center and it works perfectly. If something happens,  and the machine fails, we can restore it. You choose the time you want to restore and it restores anything. 

We use Quest Rapid Recovery for disaster recovery of certain servers. This tool helps us restore live data. It also helps us with processes that can be from either a backup appliance or a backup disk.

It has helped our organization. In some cases, we feel that some data is missing from the disk. In such scenarios, we restore the HomeDesk with a set of time demands that are determined according to the application that you want to either restore or work with. You do not need to wait and can continue working.

We use Rapid Recovery to protect our core server applications, data, principal end-users who may have local information as well as information on the network.

The ease of use has reduced the admin time involved in our backup recovery operations. It hasn't reduced the daily monitoring of things, but it has reduced the managing of tapes daily and weekly by at least three hours of time a week.

Rapid Recovery really hasn't changed the way that we function. We were doing everything before that we do today. It's just that we do it with less effort now that we have Rapid Recovery, such as not having to handle the physical tapes and being able to do backups locally and have them replicated offsite. But it's less time.

It enables us to recover complete systems, applications, and data with little or no disruption to the work environment. That's very important. The amount of data that we generate in a day is very large and we can't afford to have a large, long protracted outage. So knowing and having our systems protected with Rapid Recovery allows us to return to a productive state quickly and rapidly so that we can continue our productions. We are a production facility and if our systems aren't working, we can't produce the product for our customers.

Using Rapid Recovery, we can have one of our servers, as long as it wasn't one of our big, crazy ones, up and going in and probably 30 minutes to an hour from a complete failure.

In the past, if we had to set up the server and then mount all the tapes and find all the tapes and all that, it could be an all-day or many-hour function, five to eight hours to get a server up and going, to one hour. It's just drastically changed our ability to get operations back up and running.