March 28, 2006 at 2:23 pm
Althought not explicitly clear in the review, the reviewer seemed to be comparing using LiteSpeed directly to a TSM server (not backing up to disk) to using TDP to backup directly to a TSM server. Backing up to a Tivoli server is not possible with Red Gate.
I am also confused about the conclusion that was made. LiteSpeed ran faster, verified backups, costs less, integrates better into sql server, and has more options than TDP but you went with TDP.
Can you please reiterate why you made your final selection?
March 28, 2006 at 2:31 pm
Couple of other things?
Why not try backing up LiteSpeed to a SAN disk. You've noted that SAN backups are substantially faster than a backup to a TSM server. LiteSpeed backups to a SAN device would be even faster than native to the same SAN device, and using Litespeed will save you 80% of that SAN device.
Also, Tape is a very volitile media and its shown over time that around 50% of backup files sitting on tape cannot be recovered from. Any best practices guide you can find says "backup to disk first". Especially for production environements. Not only do you get substantially faster speed but you also get the reliability of disk over tape. Typically the reason why people buy backup compression utilities is because it allows them to backup to disk without spending the budget on SAN space. Typically people only backup to TSM as a last resort.
Glad to see an open discussion of backup and restore practices... keep it coming.
March 28, 2006 at 9:31 pm
Disk vs. tape: It's not about backups--it's the restores that count. If they want a database restored, they generally want it restored RIGHT NOW... and you'll get it done faster if you're reading from disk, not from tape. (You are storing your tapes off-site, right?)
My general backup methodology is:
- Backup databases to disk
- Copy backups to tape
- Keep the disk backups around for a while
- Keep the tapes around off site for a month or two, to give management and auditors warm fuzzies. (I figure if and when you need those backups, you'll probably need to line up new hardward first...)
With a judicious combination of complete, differential, and transaction backups, it's entirely feasible to keep backups permitting restores reaching a week or more in the past on disk... if the sizes aren't prohibitive. SQL LiteSpeed's compressed backups make this feasible for large databases -- as would any DB-to-disk backup utility that produces compressed backup files.
Philip
March 29, 2006 at 7:23 am
Thanks for the all the feedback and the spreadsheet. I thought I try to respond to some of the comments.
Litespeed free un-compress utility:
I did not test this tool, instead I talked to the vendor about how it worked. It takes the compressed backup and uncompressed it on the server. Then you run a native SQL Server restore. The server would require enough storage for both the compress and uncompress files during the decompression process. The overall time it would take to restore the database would be at least twice as long if you didn't have Litespeed installed. I believe Litespeed's restore should be freely installable on all servers. But I don't own the company.
Prod and Cons using SQL Server Native Backups:
PROS
1) It's included with SQL Server and is always available
2) It's natively supported by SQL Server
3) In my tests it provided reasonable backup and restore times
4) Includes Backup verify
CONS
1) Uses more disk space
2) No Direct support for TSM
Network Attach Storage:
Networks attach storage uses a shared IP Connection while a SAN has a faster direct connection. I did not see the benefit of buying more network attach storage over SAN or TDP.
BMC SQL-Backtrack:
I did not know of this product and my research of products that have TSM as a backup option to not uncover it. Looking at their website and reviewing their online documentation for the product, I didn't see what benefit it would have over TDP SQL unless you are using other BMC products.
Litespeed Run Times:
Litespeed's using disk runtimes were slower than the native backups and restores. It was only a few minute difference not enough to justify one product over another. I can only speculate why Litespeed was not faster. Litespeed seems to rely heavily on its compression routines to speed up backups by issuing fewer writes to disk. The restore would execute faster because of fewer reads. The faster the disk is, the less influence this would be. Again this is just speculation.
Recommending TDP:
Neither product was recommended because I thought both products backup/restore runtimes using TSM took to long. I only presented the results of my findings and my thoughts about the products. A service level agreement (SLA) with the business needs to agree upon before the best solution is chosen.
Dude not looking at Red-gate:
I have yet to evaluate a product that I did not have problems with. Then when I contact them for support, I would need to convince them there is a problem. So I limited the number of products to perform tests on. Was it a 100% fair to everyone? No, but I get tired of vendors contacting me every 3-6 months after I download one of their products.
Not clear in the review:
The timings I reported for disk where using a Hitachi SAN. Litespeed backups and restores to Disk (SAN) ran a little longer than SQL Server Native commands. No selection has been chosen until a SLA is agreed upon.
Couple of other Things:
Backup to Disk is very advisable for the windows and UNIX environments. My original recommendation to purchase Litespeed was driven by that bit of advice. But since IT manager who approves all purchases sees that we are using TDP for Oracle to backup a 650 GB database why not use it for SQL Server. He seems to be unaware the backup time for that database is 16 hours and they have never restored from it. Yes, I am worried of the implications of that as well.
Disk vs Tape:
Tape backups will be kept both onsite and offsite. I like keeping backups on disk (SAN) around but we have only room for one backup on SAN. The old backup back up was not being deleted until a new one. Differential backups are no good without the full backup. So a keeping both a full backup and differential backup on disk only takes up more space. SAN may be cheap but getting more of it is not easy.
Sorry for the confusion contained in the article. Unfortunately when writing about a subject that I am familiar with I tend to gloss over something's.
David Bird
March 29, 2006 at 1:31 pm
Need license to restore on another server
LiteSpeed never requires a lic to restore. We won't hold your data hostage. You can use the extractor, or install the demo and restore. Even if it tells you the lic is expired it should still restore.
Litespeed Run Times:
Litespeed's using disk runtimes were slower than the native backups and restores. It was only a few minute difference not enough to justify one product over another. I can only speculate why Litespeed was not faster. Litespeed seems to rely heavily on its compression routines to speed up backups by issuing fewer writes to disk. The restore would execute faster because of fewer reads. The faster the disk is, the less influence this would be. Again this is just speculation.
I am also very interested to find out why LS was slower in your environment. We run alot of test with TSM, Tape, and Disk and do everything we can to keep speed as fast as possible.
If you would like to take this off line I would be more than happy to talk with you about your experience.
Wesley Brown
SQL Server Domain Expert
Quest Software Inc.
March 30, 2006 at 5:58 am
Having used Litespeed extensively , on a SAN and DAS, I will happily state that Litespeed did as claimed and ran very much faster than native. The restores were also a factor of serveral times quicker.
Having "struggled" with SAN performance over the years I would suggest the SAN be examined with some interest .. I'd be interested to know what throughput you got for the various backups and restores.
Maybe little databases don't perform so well, but you did mention minutes, my recollection of the backup time for a 4 gb of data database was around 1 minute or less, the restore was a similar sort of performance. DBA's I know who use Litespeed rave about it - ( I'm only considering backups to disk btw )
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
March 31, 2006 at 6:37 am
My boss went out and bought TDP for all of our SQL Servers. Personally I see no benefit to justifying the huge cost based on what Microsoft ships with SQL Server for free. He likes the ability to have one product that controls all of our backup/recoveries for all servers via Tivoli and backups of Oracle and SQL Server all the same. I dislike the GUI for TDP when you take a backup of a prod db and restore it to another server. You have to fake it out via another dsm.opt file AND when you restore the db from prod to test if the test db has a different name the GUI says it is restoring the prod db name. It freeked out our other dba at first thinking he was restoring the prod db instead of the test db.... !!
May 6, 2006 at 10:55 pm
This article is flawed. The reason you saw slower times for TDPSQL and Litespeed is because your TSM server is slow. You should have added another test and backed up Litespeed to the same disk as the native SQL.
At our company we used to backup our production database (800GB) to TSM w/ TDPSQL and it would take ~11hours. We now use Litespeed -> TSM and our backups take 1hour 10minutes, and the backup file shrunk to 160GB. Also we have a gigabit connection to the TSM server, and we do not backup directly to tape. We backup to a TSM disk pool which is SAN disk.
We are very happy with Litespeed, best money we have spent in a while!
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply