Idera SQLsafe Review: Too Many Showstopper Bugs

I hate badmouthing a product on the internet because it’s permanent. It goes into search engines, people looking for “SQLsafe sucks” run across it, and it decreases sales. Here’s the thing, though: Idera SQLsafe v4.5 really does have some crippling products that limit its use and make it a bad choice for database server backups, and I’ll explain why.

First, a little about me and my qualifications to talk about SQL backups. I’ve been using SQLsafe v3.0 and v3.1 since I started at Southern Wine & Spirits in 2005. Before I first purchased it (SQLsafe, not Southern Wine, ha ha ho ho), I got demos of all of the competing SQL backup compression products out there and put them in our labs for a couple of weeks. I did speed benchmarks, CPU load tests, and compression tests. SQLsafe won out as the best balance of features versus price, and while I ran across a couple of really small bugs, they weren’t enough to discourage me from putting it into production. I relied on SQLsafe to back up a handful of servers from a ~200gb OLTP server to a 2-terabyte SAP BW data warehouse, and I was a happy camper.

At the Professional Association of SQL Server Summit 2007, I got a demo of their latest version (4.5) and walked away pretty impressed. They showed how I could quickly and easily restore single tables out of a backup, and how the product was flexible enough to restore to different databases and different tablenames. Sold. Plus, the central management service finally runs on 64-bit servers, and since I’m converting to an all-64-bit environment, I decided to give it a shot. I have a maintenance agreement on SQLsafe, so I downloaded the new version and installed one server for starters.

First SQLsafe Bug: Can’t Create Backup Policies

SQLsafe backup policies can cover all databases, only user databases, only system databases, or specific databases. I wanted to set up two policies — one for user databases, and one for system databases, because you can’t have one plan cover both full-recovery databases and simple-mode recovery databases. The system database policy worked fine, but the user database policy did not. It warned me:

“A log backup cannot be performed on database “master” while the recovery mode is SIMPLE.”

Uhhh, news flash to Idera, master is not a user database. I opened a support ticket with Idera (#00023903) and they passed the bug on to developers.

Idera said that until the bug gets fixed, I have to create backup policies for specific databases – meaning, choose the databases manually, and check off each of them.

Side Effect #1: New Databases Aren’t Backed Up

Since I have to pick databases manually, any new databases aren’t automatically added to the SQLsafe policies.

For me, this was a showstopper, and the end of my production evaluation. I have a hard and fast rule: nothing goes into production that requires more of my time instead of saving me time. New things have to make my life easier, not harder. With SQLsafe 4.5, I would have to do a daily check of all databases and manually add them to the SQLsafe policies. Sure, I could roll my own integration code, but I’m also dead-set against that as well.

Side Effect #2: Manual Policies Can’t Cover All User Databases

SQLsafe policies are implemented via SQL Agent jobs, and a single job step can’t exceed 3200 characters. Because the SQLsafe job code is wordy and lengthy, they quickly violate the 3200 character limit even with less than a dozen databases.

As a result, I had to make multiple policies, grouping the databases together. Thankfully, I did the eval on a server with under a dozen databases, so I was able to make do with just two policies, but on my real production servers, some of them have dozens and dozens of databases. I’d have to manually manage handfuls of policies, and I’d have to stay on top of which databases were in which policies.

And it gets worse: each policy has its own independent schedule, so I completely lost control of my backup window. I didn’t have a centralized way of knowing that my full backups took X minutes and my t-logs took X minutes, because I was ending up with multiple policies.

Second Bug: Object-Level Restore Doesn’t Work with Identity Numeric Fields

SQLsafe v4.5 has a new object-level restore option. During backups, it scripts out objects in order to enable SQLsafe to restore individual objects later.

If the database has identity numeric fields, SQLsafe does not back up the database. (There may be other database design issues that also cause SQLsafe OLR to fail, but that’s the only one that caused me problems.)

An enterprise-ready backup package would say, “Okay, I can’t back this up with object-level restores, but I’m going to back it up the old-fashioned way and just log an error.” Instead, SQLsafe v4.5 just skips the database altogether and logs an error.

Idera’s support said the workaround was not to enable OLR on those databases. Unfortunately, OLR has to be turned on or off at backup time, not at restore time, so database admins have to have separate backup policies for databases that do support OLR, versus backup policies for those that don’t.

This is especially problematic because it means even if they fixed the first bug (allowing a single policy for all user databases), we still couldn’t have one backup policy, because some of our databases have identity numeric fields. I still want the ability to do OLR in the databases that can support it, so that means…

Side Effect #3: Backup Policies Become a Mess

My backup policies on this first server now look like this:

• System databases
• User databases that don’t support OLR
• User databases that support OLR, part 1
• User databases that support OLR, part 2 (because part 1 was more than 3200 characters)

This is not an improvement.

Third Bug: SQLsafe Agent Fails to Install, But Says It Succeeded

Pretend for a second that this product is actually deployable. I said to myself, let’s keep giving this another shot, and let’s deploy it to a disaster recovery server and test it there too. In the management console, I right-clicked on the target server and installed the agent. The console reported a successful install.

Or did it? The console’s server list reported that the server still had no agent installed. Eh? I refreshed the view, restarted the SQLsafe services on the target server, and finally rebooted the target server. I tried installing it again, and got another success message, but still no new agent. Only after reviewing the application logs on the target server did I discover that the install was failing with a message that I had to uninstall the previous version of the agent.

I reported this to Idera support, who responded that yes, the install wasn’t actually succeeding despite what the management console said. I had to uninstall the SQLsafe agent manually on the target server, and only then could I push out the new agent.

I would have understood if the management console had reported an installation failure, but quite the opposite, it reported a successful install. It didn’t report an error, didn’t say there was a problem, it reported success.

That bug is flat-out unforgivable unless I’m the only guy who ever bought Idera SQLsafe prior to v4.5. (I’m beginning to wonder if that’s maybe the case.)

Bottom Line: Nowhere Near Production Quality

I could excuse a lot of these bugs in early alpha or beta code, but these types of bugs are simply inconceivable in production code that’s responsible for backing up mission-critical databases.

Idera SQLsafe v4.5 is not ready for production, and shouldn’t be purchased by any database administrator.

I sincerely hope the code improves quickly. I wish I had the object-level-restore ability of v4.5, but I can’t put my production database servers at risk like this. I’m already rolling back my servers to v3.1.

Update on November 7, 2007 – followup blog post, “Idera SQLsafe Followup: Problems with Restoring Databases”

Update on February 10, 2007 – I get an email at least once a week whether a new version of SQLsafe fixed the bugs.  We stopped using SQLsafe, so I can’t say, but you can get an evaluation version from Idera to find out by testing in your own environment.

Brent Ozar

Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.

Website - Twitter - Facebook - More Posts