Quorum OnQ Reviews

We mostly use it for disaster recovery and high-availability. In case of a server failure, we can deploy a server and have the location up and running instantly, within minutes. And then, once the location closes, if we need to, we can do a full restore of the server to new or similar hardware. If it's something as simple as the server going down or becoming unresponsive, we can bring it up, use it for what's needed, and then just transfer the files that needed changing.

The locations don't even know that anything has happened because, if a server goes down they call me. In minutes, I have a virtual version of that server up and running as if nothing had ever happened. It's actually pretty awesome. It's not necessarily that it saves me time on anything. It saves me the headache of losing productivity from my users. In other words, if something were to happen to a physical server, none of my users would lose productivity throughout the day, and the business keeps going as usual.

An example of how it has helped us is that about a year-and-a-half ago, we had a physical server that completely failed. It was our primary domain controller. It's what sends all the instructions to every other domain server to tell it what to do. If it doesn't communicate, we lose a lot. We noticed weird errors happening on the server. We had a hardware technician here and we tried to check things and we tried to repair the actual file system but we lost the array so we lost the data. But, because of Quorum, within two minutes, the branch was back up and running. They knew nothing had happened.

That night, we completely restored that server. It took us about an hour to get everything back up and running. There were some minor configurations that we needed to change after we got the server up and running, the next day. And everything was back to normal. If we hadn't had Quorum in place, within 24 hours, all of the servers would have been out of sync. We would have lost the entire domain and have had to rebuild the domain servers from scratch. That would have taken weeks.

We had noticed the errors at around five o'clock in the afternoon and we decided to wait a little bit. Around six o'clock is when the server failed. By seven o'clock we were back up, everything was running, and we went home for the night.

The main purpose is as a faster disaster recovery solution. The secondary use case is for quick, daily backups.

About two years ago, I had a Windows 2008 Server for the fire department on which two hard drives dies almost simultaneously. HPE was nice enough to send me a couple of new drives overnight, but it didn't help the situation because the server was dead. So I spun up that entire fire department server, which had SQL running on it and a couple of databases that are necessary for dispatching fire calls and getting the information out of our dispatch system for tracking, timing, etc. I was able to bring the server up in about five minutes. I left it up and running for about two weeks.

I didn't do the bare metal restore because it was a Windows 2008 Server that was scheduled to be replaced that year anyway. I just let it run for a while and when I got new hardware I built it up as a Windows 2012 Server, at the time. I was able to do it on my timeline, rather than being in a panic situation and having to get the server back up. The entire time, while it was running in this virtual host, it was also backing up at the same time. If necessary, I could have gone to any of my backups, which sounds weird — it's a backup of a machine that's running on a machine — but I could have gone to any of those backups. That was the only instance that I've had to rely on any of its features, above and beyond just restoring files when people mess up and delete something.

The case of somebody overwriting or deleting something by accident, where I have had to recover a file or data, happens more often than I would like to admit. I find myself having to restore a one-off file about once a month. It happens more around budget time. People take the stuff from last year that they think they made copies of and make them into blank documents for this year. Inadvertently, they're working on the wrong ones and I get to restore those. That seems to happen at least once or twice every budget year. 

Another scenario is that somebody comes to me and says, "This file was supposed to be in this directory. I either accidentally overwrote it or I accidentally deleted it a few weeks ago and I need it back." If they're really good about it, they'll tell me the name of a file or a directory, which gives me something to work with. Hopefully, they'll give me a rough time that they know it existed. I'll just start working through snapshots. I'll open up AD servers that have all of my file shares on them and I'll pick a date. I'll start with January first. If the file is not there I'll move to January second. I'll continue going through all of my snapshots so that I get them the absolute latest and greatest one that there is and which is still functional.

Another instance where I'm having to restore on a somewhat regular basis is when people leave, depending on the situation and why they left. They may not be doing it maliciously or they may be trying to either cover their own tracks or trying to make it difficult for the next person. They'll delete everything that they've got. I'll go into their Outlook and they've got three emails, but they've been here for four years. So I'll have to restore all of their mailbox from a few weeks prior to their putting in their request to leave, and start restoring files as well. That happens about twice a year where I have to go to that extreme.

There isn't a cut and dry process in that situation. When I get notification that somebody is leaving, I back up their email, for records retention. If I realize all their mail is gone, or it seems like there's stuff missing, I'll start restoring old stuff from the past and see what they got rid of. It makes the life of the person who will be following them in that job position about a million times easier if they've got some idea of the communications the previous person had or any notes or documents they had for that job.

I also benefit from the solution's deduplication, especially with their new software release, and how they're arranging the storage for the disaster of virtual machines. It is handled differently. It doubled the amount of space that's available for my backups. The deduplication helps, obviously, because I'm not having to back up the same caches over and over again.

We're still old-school. We have a tape backup system that we use for the majority of our servers. onQ is kind of like doubling our protection. We like the fact that it's a complete disaster recovery solution, so if we ever lost a server, we could spin it up virtually and get our server repaired and nobody would miss any work or have even noticed a difference, other than possibly a little speed, and we're not even certain they would notice that. 

We also use it for general file recovery every once in a while when somebody deletes something they shouldn't have. We use that scenario as our test, every now and then, to go in and make sure we can still recover stuff. 

We use it for "insurance." We're in central Florida and in the Panhandle and it's a hurricane-prone area. We want to have things covered as much as possible, which is why we back up to the opposite office.

We have one in-house server in each of our two offices. The box in each office cross-replicates to the other. We try to put as little in the cloud as possible. We are slowly moving some things to the cloud, but as far as company data goes, we really want to manage that in-house as long as possible.

We had an instance a few years ago where we lost one of the cards for the RAID controller on one of our servers. When they put the replacement parts back in it didn't recognize our RAID at all. We had to redo the RAID and then we did a complete restore off of the onQ's and it took about three hours. Our server was back exactly where it was the day before and there was very minimal downtime as far as that kind of endeavor is concerned. It worked flawlessly. We've never actually had to do it off of the tape system, but I would think it would be exceptionally tedious because it would take at least the better part of the day to set the server up. And then you would have to worry about copying the directories and making sure you got everything. To recover all the user accounts and system accounts, it would get complicated fairly quickly.

At that time, with Backup Exec, which is made for the tape backup systems by a competitor, I don't even know if you could completely back up the entire volume. You could do the files, but I'm not sure it would do the operating system. The newer versions of software claim they can, but it's still a little bit of a crapshoot as to whether it really recovers the whole system. If it doesn't, then you have to set the server up, re-install the software, and then try and copy your files back. It would be pretty ugly.

Mostly, onQ gives us confidence, knowing that we're really covered if we really have to bring the systems up. It's a complete solution, whereas tape backups, in some of those situations, are not designed to actually spin the system up. They're designed to, at best, copy it to another machine and hope it works. It's comparing apples and oranges. onQ really is a complete system that you can bring up in an emergency. Instead of being down for a couple of hours, you're down for a matter of minutes in a lot of cases.

We launched all of our advocacy departments through Quorum next month. We are in the process of uploading all of our data and creating custom fields.

We are moving to the Quorum platform fully. Phone to Action is dissolving. We are in a training environment that can transition seamlessly to a live environment.

I use the solution in my company as a backup and disaster recovery system.

The most valuable feature of the solution stems from the fact that I can do multiple backups because it offers a backup snapshot functionality.

Backups, file recovery, DR capability, and instant VM recovery are our primary needs and the OnQ system does those expertly.

Our infrastructure is a combination of hosted and on-prem. Co-locating our HA appliance in the data center near our SAN environment provides a knockout combination of speed and security, and the environmental fears are not present. This bunker approach protects our primary HQ data and also backs up remote servers across our WAN. We cover all our bases by protecting every server and VM in our environment, and even our specialty machines. The HA/DR appliances also provide us with a rock-solid implementation of DR.

We've used the Quorum OnQ appliances, HA and DR, for the past six years. It is a rock-solid platform that has served us well. We recently retired our aging OnQ appliances and upgraded to the new generation of OnQ servers. The change has been impressive. The new hardware is substantially faster and we are able to apply the OnQ solution to additional business segments in our company as the backup times have decreased between five and tenfold.  We are now retiring other backup solutions as we push out protection via OnQ to other business units.

The onsite version keeps our backups for all of our NOC servers, which is everything operational. We get backups every four hours or so, and should something happen — someone deletes something or a server's hardware goes out — we're able to restore that locally, very quickly. The Quorum will run a virtual machine, the recovery node of the server, from the latest backup, within minutes of having an issue.

Our deployment of the solution is both on-prem and cloud. We're only sending a few specific servers to the Quorum cloud, which hosted by them. We have our onsite device as well which backs everything up.

We had a few instances where someone who had access to some accounting shares got infected and no one could access those files. We were able to lock down the infection on that person's computer and, within an hour of it being detected, restore files to four hours prior, when there was no infection. So we were only set back on a few files by a few hours instead of a day or two.

We've also had hardware failures on physical servers. We were able to restore the recovery node and bring the server back up, with the users unaware that there was ever a problem, other than losing connection briefly while the recovery node came online. There may have only been a few hours lost instead of a day, where we had to fix the physical server and then bring it online.

With the restore function on the Quorum, we're able to go down to the individual file level for each backup, and we have 40 or 60 backups available. We are able to restore the files to exactly where they were, through Quorum's interface. It's very easy to go through if you've ever used a file system as a system administrator. It is very intuitive to navigate and recover the files to exactly where they were when they were backed up.

The most valuable feature of Quorum OnQ is quick recovery. We call it a single-click recovery. If any server goes down, crashes, or experiences downtime, we can bring up the DR (Disaster Recovery) server in just two minutes. We also have a "Single Pane of Glass," wherein we work with only a single window. You don't have to use multiple windows to perform basic tasks like failover or failback.

Quorum OnQ's user interface is not very attractive and should be made more attractive.

The turn-around time of Quorum OnQ's customer support should be improved.