September 14, 2011 at 1:58 pm
We are migrating to sql 2008R2 standard edition which does have backup compression option.Currently we are using Litespeed and plan to stop using once we move to sql 2008r2. I did some testing of litespeed Vs Sql 2008 r2 compression and seems like compresses more than litespeed, disk I/O is less with sql back up but CPU usage is more when we use compression feature in 2008r2. I was wondering has anyone else tried to replace any other backup software with sql 2008r2? We only use litepspeed to backup/restore, we do not use any other feature.
September 14, 2011 at 2:11 pm
There are some time since I tried this, so please take my comments with a grain of salt.
With native backup, you can only specify whether to use backup compression or not, whereas LiteSpeed can use different compression levels. I suspect that your findings are due to using standard compression level. When it comes to backup size and IO, SQL Server native backup cannot really compete with LiteSpeed if you select a high compression level. It will use a lot of CPU power though, but in many environment this is quite acceptable as backups are running at times when there are little access. As for restore, decompression is always using less CPU power than compression. It will still add more CPU load, but it will also be able to restore the backup way faster than the same backup uncompressed, as the disk IO tends to be the factor limiting the performance the most.
September 14, 2011 at 2:48 pm
okbangas (9/14/2011)
There are some time since I tried this, so please take my comments with a grain of salt.With native backup, you can only specify whether to use backup compression or not, whereas LiteSpeed can use different compression levels. I suspect that your findings are due to using standard compression level. When it comes to backup size and IO, SQL Server native backup cannot really compete with LiteSpeed if you select a high compression level. It will use a lot of CPU power though, but in many environment this is quite acceptable as backups are running at times when there are little access. As for restore, decompression is always using less CPU power than compression. It will still add more CPU load, but it will also be able to restore the backup way faster than the same backup uncompressed, as the disk IO tends to be the factor limiting the performance the most.
We have always used compression level1 for backups using Litespeed.We might not want to increase the compression level because there are nightly ETL jobs run which are little resource intensive. What metrics have you used to see if I/O is better in LiteSpeed than native? With compression level 1 i see that SQL native uses 1/10th of I/O what litespeed does?
September 15, 2011 at 12:14 am
As I said, take it with a grain of salt, there are some time since I tested it 🙂 When comparing backup, which is sequential read/write, I measure thoughput. I am not all that interrested in number of IO operations per second for sequential disk access. I am for random (like database files) though.
September 15, 2011 at 7:41 am
I found that the backup compression in SQL Server 2008 is better than the Redgate Backup tool we used to use. Even if the compression was not quite as good or the fact you can't configure the level of compression you also have to factor in the cost of a 3rd party backup tool, in my case with 30+ servers it was quite a saving.
I am more concerned with the time taken to backup than the load, I try to keep a window of time relativly quiet over night to carry out backups.
Thanks
Chris
September 19, 2011 at 3:57 am
SQL Server compression is indeed favourable when compared to 3rd party products such as Litespeed or SQLBackup. The big issue for me is that when enabling TDE compression is void. The 3rd party products offer strong encryption and compression all in one package. They also have intelligent features such as backup retires until successful and network resilience.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply