SQL Server backups vs SQL LiteSpeed

Question

Post reply

SQL Server backups vs SQL LiteSpeed

Summer90

SSC-Dedicated

Points: 32864
More actions
June 17, 2004 at 6:52 am

#108394

I would like to hear from anyone using SQL LiteSpeed for their SQL Server db backups. Do you use it for ALL of your databases large and small. Had any problems? Is it worth the bother of another layer of complexity for recovery, especially disaster recovery?

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply

mimorr SSCarpal Tunnel Points: 4850 More actions · Answer 1

We use it. I use it for every one of my databases. I have 6 servers in one location and one in another and have it installed on all 7. I have had only one problem with the software in the 8 months I have been using it; that was a permission error on one server. Otherwise, it has been great and saves us tons of time.

I have over 30 TB of SQL data spread across 3 SANs. I use it for disaster recovery, because I can group like databases together on one LTO tape and take the tape off-site. We use ArcServe to backup the LiteSpeed backup files.

In the past, we had to take the database offline, or make a Native SQL backup of the data. Taking the database offline is becoming less possible as the number of hours my users want to work increases. The Native SQL backup seems to take the same amount of space as the database, and I usually don't have that much free space on my server.

One tip I have for you: Native SQL backups don't assign file extensions and so many years ago, I got in the habit of using *.sqlbak so I would know at a glance what the file was. When I was in the process of migrating to SQL LiteSpeed, I needed to differentiate between the different files, so I used the *.sqlbakls extention. That way I know which backup utility I used.

Hope this helps!

Michelle

MikeM-150936 SSC-Addicted Points: 452 More actions · Answer 2

Let's try this again... tried posting once, but some gremlin must have blown it away....

Long story short... We use it here, but have had mixed results. I am an optimist by nature and am hoping that the problems we've experienced are more of the 'Diamond in the Rough' nature and not indicative of impending doom.... One of my DBA's wishes we never got the product.

We've been through several versions thus far and most troublesome problem we've had along the way was that we could backup databases, but the validation would fail -- and when it did, the only way we could get the backup restored was to first use SQL Litespeeds (SLS) Extractor utility. In the finally analysis, the problems seems to be related to how SLS uses the SQL Server VDI when doing multi-threaded backups... the workaround was to force a single-threaded backup... you still got the compression of space, but not of time...

We're now running 3.0.124 mostly and has been the most stable, except it has one caveat as well in that we have a few (and quickly dissapearing thankfully) databases that reside on a SQL2000 server but have a compatibility level of SQL6.5... for some reason 3.0.124 chokes on them, and we haven't got a fix from imceda for it yet... I suspect I'll be gone of those old db's before I see a fix... other

Another caveat to be aware of is if you use other 3rd party tools with your dumps/logs. We do. We use Lumigent's Log Explorer (excellent product) to research transaction logs. We have v3.0 in production and it doesn't like SLS TLog dumps. I've been told but Lumigent that v.40 fixes that (we'll see). We are also looking to invest in their Entegra product which chokes on SLS Tlogs as well... so we'll probably wind up doing SLS backups for database dumps, but Native SQL Server ones for TLogs... hope this helps.

-- Mike

Summer90 SSC-Dedicated Points: 32864 More actions · Answer 3

Thank you very much. Yes, we use Log Explorer also... never thought about that.. interesting. Most of our dbs are small (under 2 gig) but a few are going to be over 20 gig.... I wondered if it was even worth the bother wondering if it was more work than its worth. In a disaster recover senario it adds another layer to the recovery procedures in addition to the possibility of us adding a second live data-center....

MikeM-150936 SSC-Addicted Points: 452 More actions · Answer 4

Markus -- Like I said, I'm an optimist by nature, and I hope things will stabilize and get better, but make sure you test the begeezus out of it... in any scenarino you can possibly muster. Our focus on getting it was to reduce the amount of disk were using on our server. We have database servers which run the whole gambit of size and structure... we've some sub-1GB databases and one or two 20GB dbs -- and it has saved a good chunk of space on all of them.

Depending on the structure of the database (very important) we've realized a 55% - 73% compression on the database dumps. Most db's hover around 70% compression, the ones that dip down to the upper 50's are ones which contain binary objects like BLOB's within tables... they don't compress very well...

Good Luck! -- Mike