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.

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.

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.

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.

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.

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.

Quest Rapid Recovery has improved our organization by making backups faster. In the past, using tape backups would take two to four days, but with Rapid Recovery, it is now completed within 24 hours, excluding the additional four-hour buffer.

We use the off-site model, where we replicate all of the current data at the end of the day. After we do our roll-up and everything, we replicate across to the Azure Rapid Recovery Server. At any given time, both servers would be in sync in the evening, with all of the data. Whatever we've got on-premises is the same as what we've got off-site.

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. 

It enables us to recover complete systems, applications, and data with little or no disruption to the work environment. Being able to recover data without interrupting the users is very important for us.

Incremental backups have saved 10% to 15% of storage cost for sure. Incremental backups have also helped to reduce the impact on our production environment or network resources. They have improved the speed.

When we had a server upgrade, we were able to restore the entire disk to another machine. It was very easy to do. This was a huge benefit. We were able to just take the data off of the Rapid Recovery backup and restore it to the new machine. We didn't really have any downtime other than the obvious meantime to restore, which was pretty slow only because the setup of the environment wasn't best practice. So, the data was stored on a USB drive that was not the standard configuration for Rapid Recovery. Therefore, it took 15 to 18 hours to get it restored, but we were able to do that on a weekend. We upgraded Rapid Recovery to the local disk instead of USB, which made it tremendously better.

The ease of use has reduced the admin time involved in our backup/recovery operations. Once the system was set up correctly, it ran smoothly. It is a set it and forget it kind of thing. 

Though I haven't noticed a huge impact, Synthetic incremental backups have helped to reduce the impact to our production environment and network resources.

We now can make hourly backups of all our servers, both virtual and physical.

It is now fairly simple for operators to keep backups automated and easily do restores, or for managers to log onto the web GUI to get a quick view on things. If you don't have knowledgeable or enough staff to troubleshoot it well and you're on contract, Dell support will do their utmost to support and fix it (so far).