10.6. Backup compression
To reduce the time and space required for backups, some organizations choose to purchase third-party backup tools capable of compressing SQL Server backups. While such products are widely used and proven, other organizations are reluctant to use them for a variety of reasons, such as the following:
Cost—Despite the decreased disk usage (and therefore cost) enabled by such products, some organizations are reluctant to provide the up-front expenditure for new software licenses.
Portability—Depending on the product, compressed backups performed on one licensed server may not be able to be restored on an unlicensed server.
Non-Microsoft software—Some organizations feel uncomfortable with using non-Microsoft software to control such a critical operational process.
In avoiding backup compression products for these reasons, many organizations choose suboptimal backup designs, such as tape only, in order to reduce storage costs. Such designs are often in conflict with their service level agreements for restoration times and acceptable data loss, and often the limitations of such designs are realized for the first time after an actual data loss event.
Introduced in the Enterprise edition of SQL Server 2008, backup compression allows native SQL Server backups to be compressed, which for many organizations will introduce a whole range of benefits and cost savings. No doubt some companies will upgrade to SQL Server 2008 for this reason alone. Although compressed backups can only be created using the Enterprise edition of SQL Server 2008, they can be restored to any edition of SQL Server 2008.
As with data compression, covered in the previous chapter, there is some CPU overhead involved in backup compression (about 5 percent is typical). To control whether a backup is compressed, you have a number of options, beginning with a server-level default setting called Backup Compression Default, which you can set using sp_configure or SQL Server Management Studio, as shown in figure 10.9.
For individual backups, you can override the default compression setting using options in SQL Server Management Studio, or by using the WITH COMPRESSION/NO_COMPRESSION T-SQL options as shown here:
-- Backup the AdventureWorks database using compression BACKUP DATABASE AdventureWorks2008 TO DISK = 'G:SQL BackupAdventureWorks-Compressed.bak' WITH INIT, COMPRESSION
Figure 10.9. The Compress Backup option enables the default backup compression to be set. Individual backups can explicitly override this setting.
As with data compression, the actual compression rates achieved depend largely on the makeup of the data within the database. Similar to data compression, the goal of backup compression is not to achieve the maximum possible compression, but to strike a balance between CPU usage and compression rates.
Given that, the observed compression rates are quite impressive considering the moderate CPU overhead. For example, as you can see in figure 10.10, the observed size of a native AdventureWorks2008 database backup was 188MB compared with the compressed backup size of 45MB. Further, the time taken to back up the database in uncompressed form was 10 seconds compared to 7 seconds for a compressed backup.
Although the actual results will differ depending on the scenario, extrapolating out the compression and duration figures to a very large database scenario promises significant savings in disk space (and therefore money) as well as time.
For those organizations with a tape-only backup approach, backup compression presents an excellent argument to move to a disk then tape approach. For those already using disk-based backups, the opportunities for storage savings and greater backup availability are compelling reasons for an upgrade to SQL Server 2008.
Figure 10.10. Backing up the AdventureWorks2008 database with and without compression. For a moderate CPU overhead, compressed backups yield significant space and duration savings.
Finally, as you saw in chapter 6, a backup produced from a database that's protected with Transparent Data Encryption (TDE) will also be encrypted and can't be restored to another server unless that server has the appropriate certificate restored. From a compression perspective, the space savings of a compressed backup on a TDE-encrypted database will be minimal. As such, I don't recommend compressing backups of TDE-encrypted databases.