We are evaluating the potential usefulness of TSM deduplication on our Version 6 TSM servers. The servers run under zSeries Linux and are currently at the 6.2.2.0 level. We would not start using deduplication without upgrading to 6.2.4.0 or higher.
Parts of our workload, such as database backups sent to the servers using the TSM API, are clearly good candidates for deduplication. Other parts of the workload, such as large collections of medical images, are clearly poor candidates. However, there are two major groups of files we are not sure about. Most of our Oracle servers regularly write Oracle exports to local disk. Each set of exports is subsequently backed up using the backup/archive client. Are exports of a given database done on different days likely to have significant numbers of matching blocks? All of our SQL Server hosts perform daily dumps (as our DBAs call them) or backups (as the vendor now prefers to call them) of database contents to local disk files. The output files are subsequently backed up using the backup/archive client. Currently, the database contents are compressed in most cases. If we could persuade the DBAs to give up the compression, would dumps of a given database done on different days be likely to have significant numbers of matching blocks? Thomas Denier Thomas Jefferson University Hospital
