The symptoms you are describing sound more like retries of files that changed while TSM was reading them than growth in the size of individual files. Having the 'compress' option set to 'no' would, as far as I know, rule out the possibility of growth in the size of individual backup files. The worst growth I have ever seen for individual files was about 30%, not the almost 100% you mention. Retries caused by changing files would be noted explicitly in the client log files.
Thomas Denier Thomas Jefferson University -----Gary Lee wrote: ----- I have at least two linux clients v6.4 tsm server 6.3.4 whose bytes backed up are nearly double the bytes inspected. Compress is set to no. I would like to find the offending files which are growing. The following script shows files backed up yesterday, for a specific node, (thanks andy raibeck), but I would like to add and order by file size. How do I add the object_id field for comparison with the contents table, but not print it? Script follows: [Script removed] The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters.
