SQL Server Hardware - Red Gate Software

Backup compression
Chapter 6: SQL Server Version and Edition Selection
SQL Server 2008 brought with it, for the first time, native compression of full, differential,
and transaction log backups. The data that will be written to the backup file(s) is
compressed before it is written out to the backup file. This makes the backup file(s):
• much smaller – in my experience, most databases usually see a compression ratio of
around 3 or 4 to 1, but this is dependent on your data
• 2 to 3 times faster – since disk I/O is reduced, and disk throughput is the main
bottleneck when doing a database backup; restoring from a compressed backup is also
faster by a similar amount.
Of course, this benefit is not completely free, since your CPUs have to do some extra
work, generally 10–20% extra, depending on your hardware, in compressing and uncompressing
the backup files. This is yet another argument for having modern, multi-core
processors, which can usually shrug off this extra load.
One common misconception is that you will not see any benefit from backup
compression if you are also using SQL Server data compression. Depending on your data,
and the number of indexes that have already been compressed with data compression,
you will see a reduced compression ratio from backup compression, but you will still see
some benefit from backup compression. On the databases I manage that are subject to
data compression, I find that the backup compression ratio falls from 3 or 4 to 1, down
to 2 to 1.
SQL Server native backup compression does lack the advanced features available in many
third-party products such as SQL Backup Pro or SQL HyperBac. For example, with native
backup compression, you have no control over the compression level, and you are unable
to do object level or virtual restores.
Microsoft SQL Server 2008 R2 Books Online discusses backup compression at
http://msdn.microsoft.com/en-us/library/bb964719(v=SQL.100).aspx.
217