SQLSafe 7.4 bugs

by Nov 4, 2014

I’ve grown a bit disillusioned with SQLSafe over the past few years. Inconvenient bugs just drive me nuts. The most recent two are:

1) We retired an old SQL server recently. Idera transferred the license to the new server and I did test backup & restore. I backed up a single, small db on the old server, then restored it to the new one. Worked perfectly, exactly as expected. Then I backed up the remaining dbs using SQLSafe x64 and immediately restored them to the new server. In Microsoft SQL Server Management Studio all the dbs showed as present and online. SQLSafe, on the other hand, showed only the original single db I had previously restored. No matter of refreshing made any difference. A quick call to SQLSafe support garnered the fix. In 7.4 one must restart both the SQLSafe service on the target server AND the SQLSafe Management Service on the management server. Once we did that BINGO! all dbs showed.

This is beyond imagination. Maybe, just maybe, if I’d backed up the dbs on the old server using SQL Server to .bak files and restored them using .bak files I could see SQLSafe not seeing them immediately, but I used SQLSafe to do the restoration. I’ve moved a lot of SQL dbs around over the years and this just isn’t going to cut it. Our developers also move dbs regularly. I need to know that I can trust SQLSafe to actually see ANY new db on a SQL server as soon as it’s live. Period, no excuses, and no restarting of services. IMHO, this bug deserves a hot fix immediately.

2. Sunday I logged into our SQLSafe management server for another reason, it also houses our Cisco firewall log analyzer, and happened to have the SQLSafe Management Console still up from a previous login (RDP) and noticed every single one of our SQL servers except one was showing in failure state, every one. That’s hundreds of GB of data! That simply never happens. I all but panicked. After calming down I went through one server at a time and low and behold every single policy with a big red X claimed backups hadn’t started when scheduled and yet when I went and looked at logs and the physical files guess what?, they were ALL there. Every single one of them!

This morning I called support and almost immediately the support rep said, ‘this could be due to the DST time change’. Then it dawned on me, the single policy that showed a green check was the policy that fires off at 02:00. Since there was only one 02:00 Sunday AM (time goes to 01:59:59.99 and then back to 01:00:00.00) that backup fired off when it was scheduled based on the computer clock. Now, that said, every one of the other policies also fired off when they were scheduled, only as GMT -0400 not GMT -0500. Why SQLSafe would think they didn’t is beyond me, but this isn’t a typical bug and had to have been introduced in 7.4 because I’ve never seen it and we’ve been backing up between 22:30 and 23:55 on every policy except one since our first day with SQLSafe.

This bug needs fixed but doesn’t need a hot fix since Idera has a few months before time changes again so assuming it can be added to the upcoming 7.5 and it’s out well before 8 March 2015 it’ll be fine.

My biggest concern here is Idera’s time to fix bugs tends to be very long, like a year or more. How long did we wait for 7.4 after the previous build was released? In the end, Idera wants us paying every year for support/upgrade contracts and there’s not been a great deal of incentive with updates/upgrades. The few times I’ve spoken with support certainly don’t justify the cost, given they’ve been Idera’s problems each time so what, as a small business with a bunch of expensive licenses, I’d really like to see is at least quarterly updates with current bug fixes included and major builds once/year.