This document explains compression in the Bucky Backup (Lite and Enterprise) Client - Tivoli Storage Manager (TSM).
Using compression in your TSM client can save storage space for your backups saving you money. Compression happens on the client side before being sent to the TSM server also sending less data across the network. The compression algorithm does use additional CPU time and may cause the backup to take slightly longer, but it will not be noticed on most systems.
Compression is an option in your dsm.opt or dsm.sys file (depending on platform). It is usually on by default in most config files, but if the option is not present compression will be disabled.
NOTE: If you make any configuration changes, the scheduler will need to be restarted for any changes to take affect.
Data that is already compressed cannot be re-compressed. Compressing a file that's already compressed can actually cause the file to grow. In TSM, this behavior is shown as negative compression. If you have client compression enabled and you are backing up a lot of compressed data you may end up storing more data than you actually have. You can check for this in the backup summary in your dsmsched.log:
2012-02-06 01:48:37 --- SCHEDULEREC STATUS BEGIN 2012-02-06 01:48:37 Total number of objects inspected: 108,7252012-02-06 01:48:37 Total number of objects backed up: 724
2012-02-06 01:48:37 Total number of objects updated: 0 2012-02-06 01:48:37 Total number of objects rebound: 0 2012-02-06 01:48:37 Total number of objects deleted: 0 2012-02-06 01:48:37 Total number of objects expired: 1 2012-02-06 01:48:37 Total number of objects failed: 0 2012-02-06 01:48:37 Total number of bytes transferred: 489.06 MB 2012-02-06 01:48:37 Data transfer time: 9.93 sec 2012-02-06 01:48:37 Network data transfer rate: 50,396.29 KB/sec 2012-02-06 01:48:37 Aggregate data transfer rate: 406.87 KB/sec 2012-02-06 01:48:37 Objects compressed by: -19% 2012-02-06 01:48:37 Elapsed processing time: 00:20:30 2012-02-06 01:48:37 --- SCHEDULEREC STATUS END
In a normal backup compression will be a positive number:
2012-02-06 00:30:13 Objects compressed by: 26%
If you're seeing negative compression on a regular basis you may benefit from turning compression off. There are three approaches:
Over time, the data stored in the TSM server will be replaced with uncompressed data, and you may save a significant amount on your bill. Unfortunately, data that's already stored will not become uncompressed just by changing the client option. There are two ways to address this:
If you want to pro actively clean up the problem files, the best approach is to find the files that are already compressed and delete them. Many of the files you have backed up are not compressed files and would benefit from using compression, so targeting only the compressed files will be the most effective strategy.
Here are some examples of files that are already compressed:
TSM provides an option for excluding certain files from compression. You can add lines to your inclexcl file or dsm.opt depending on your platform:
exclude.compression /Users/jones/proj1/file.zip exclude.compression /Users/jones/proj2/* exclude.compression /.../*.zip exclude.compression /.../*.gz
The COMPRESSALWAYS option controls whether TSM will continue compressing an object it grows during compression. TSM monitors the file size and detects if the file grows due to compression. The default, if not specified, is YES. If COMPRESSALWAYS is set to YES and it detects growth during compression, it will continue to compress the file and negative compression will be the result. If NO is specified, it will stop sending the object and resend it uncompressed.
WARNING: This may cause a lot of extra data to be sent during a backup and may significantly increase your backup times.