Have the permissions been changed? Changes to extended attributes
cause the files to be backed up. Changes to permissions does not cause
the last modified date to be updated, if i remember correctly

Any new filespaces for those nodes on the TSM server?

Also, has the dsm.opt file been changed to include a new drive? Or, if
the dsm.opt says 'domain all-local' and a new drive has been added,
TSM will automatically backup that drive.

Do these node definitions have a clopt defined? Has the clopt from the
TSM server side?

Check on the Windoes TSM GUI and show ACTIVE and INACTIVE files. If
you can identify one or more of these files that are suddenly backing
up, the GUI will show the last update and backup date of those files.
Also, dependent on how many versions you retain, you can see if they
were backing up previously

Just a few things i would be checking in the first instance

Regards

On 18 October 2012 16:51, Thomas Denier
<Thomas.Denier AT jeffersonhospital DOT org> wrote:
> 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.
>
> Thomas Denier
> Thomas Jefferson University Hospital