Thank you very much; that turned out to be exactly what happened. One of our client systems has an application built around a database made up of ten files. Some of the files change on any day when the application is used, and some change much less frequently. The database has had chronic problems with both integrity and recoverability. The application vendor insists that the recoverability problems occurred because different database files were backed up on different days. My management is well aware that this is nonsense, but felt that it was necessary to back up all ten database files every day to pressure the vendor into addressing the real issues. I set up a new management class with 'mode=absolute' in the backup copy group. The new class was tied with our existing default management class for longest retention period. The TSM documentation does not specify how ties are resolved when selecting a management class for directories. At least some of our client systems used the new management class for their directories.
Best regards, Thomas Denier -----Steven Harris wrote: ----- >A distant possibility is that the tree being backed up has a >different >management Class and that has had its copymode set to absolute. >>> -----Original Message----- >>> From: ADSM: Dist Stor Manager [mailto:[email protected]] On >Behalf >>> Of Thomas Denier >>> >>> We recently noticed an unexpectedly rapid increase in database >space >>> usage on one of our TSM servers. This seems to be the result of >two >>> Windows clients that are consistently backing up hundreds of >>> thousands of files every night. We checked our other two TSM >servers >>> and found two more Windows clients behaving this way. >>> >>> In all four cases the behavior started during the same backup >>> window: >>> late October 9 and early October 10. >>> >>> All four systems are in the same Windows domain. The domain >>> administrator does not recall any noteworthy updates on October >9. >>> >>> One of the Windows administrators involved looked at dsmsched.log >and >>> reported that the backups include large numbers of files that >have >>> not been updated or even accessed recently. >>> >>> The four Windows clients have, among them, three Windows levels >(XP, >>> 2003, and 2008), two TSM client levels (5.3 and 6.2), and three >>> groups of people responsible for system administration. >>> >>> The three TSM servers involved include one 5.5 server and two 6.2 >>> servers. All run under zSeries Linux. >>> >>> I would appreciate any suggestions regarding possible causes for >this >>> behavior.
