Why I switched backup software from Ahsay to Asigra

Posted on 07. Jul, 2010 by Matt Gorecki in Blog

I’ve recently switched backup vendors from Ahsay to Asigra. Go! Elephant started using Ahsay in 2006 just as version 5.0 was released. I used both the OBM and lightweight ACB versions and, for the most part, they worked pretty good. Over the last few years, though, my issues with Ahsay mounted and I needed to switch to a more reliable software product. After a 2 month demo process, I found that Asigra fit the bill. Here are some my major concerns that lead me to switch.

Corrupt Indexes

Corrupt file indexes were my biggest problem. Ahsay uses a proprietary folder structure to store the backed up files both on the server and on the local machine (if doing a local backup as well). The index itself is a flat-file database and is used to keep track of these directories. On occasion, for no discernable reason, the local index will corrupt itself and prevent the local backup job from running. This causes the backup job to report a total failure, even though the remote backup job completes just fine. The only fix is to manually delete the index files on the client’s server and force Ahsay OBM to rebuild it.

I’ve experienced corrupt indexes in all versions of the 5.0 series including the latest 5.5.7.0. Not only does this eat up my time, but frustrates my clients.

Memory consumption

Ahsay OBM uses multiple Windows services to function. There is the core backup service, the auto-update service (more on this below), and the Continuous Data Protection (CDP) service. The core backup service is reasonable; it only consumes memory and processor while a backup is running and even then RAM usage maxes out around 200 megabytes.

The real culprit is the CDP service. On my personal workstations, the CDP service uses over 300 megabytes from the moment the Windows starts, and I’m not even using CDP! There is no way to turn the CDP service off short of manually turning it off in the Windows Service Manager. It’s absolutely unacceptable to consume close to 50% of a machine’s resources on a service that isn’t even being used.

Software updates and patches

As mentioned above, the Auto Update service runs continually. The only problem is that it doesn’t automatically update Ahsay OBM. Well, sometimes it does. When it feels like it. According to the documentation, update checks are to take place before every backup job. Sometimes the update downloads immediately. Other times an update doesn’t occur for 3 or 4 weeks, even though Ahsay OBM is checking for updates daily.

New features are slow to come out

Ahsay has a great roadmap of where they are taking their backup software. Unfortunately, the important features and bug fixes are usually glossed over in favor of superficial updates. The CDP memory issues and auto-update problems are brought up over and over again on the Ahsay forums, but are still unresolved as of today.

Encryption key management

Encryption key management isn’t a deal breaker, but Asigra’s implementation is much better. In both cases, if the encryption key is forgotten, the backed up files are useless. Asigra offers the ability to store the encryption key on the Go! Elephant backup server, encrypted of course. In the event of a system failure, I can provide the encrypted encryption key to the client and they can use it to restore their files. The process is still secure because I never have knowledge of the plaintext encryption key at anytime. With Ahsay, if you lose your encryption key, it’s gone forever, along with the ability to unlock your backed up files.

If you are interested in either the Asigra or Ahsay backup products drop me an email. I would be more than happy to discuss the pros and cons of either system.