Well, from the attached file, I saw the file was backed up only 5 or 6
times since May. I can't say *why* TSM has multiple backups of the file.
Some possible reasons include:

* incomplete -incrbydate backup. If you use -incrbydate, check the last
backup time for the file system
* selective backup
* mode setting of ABSOLUTE instead of MODIFIED in the copy group
* other non-obvious changes, such as security attributes or creation date
(use "dir /tc some.file.name" to see the creation date)

Have you tried testing backup of a single file, i.e.:

   dsmc incremental some.file.name

and then immediately repeating the "dsmc incremental" command? Does it
back the file up yet again? If so, you can try tracing the backup like
this:

   dsmc incremental some.file.name -traceflags=policy,fioattribs
-tracefile=dsmc.trc

This will show you policy info where you can check the copy group modes.
Below that, you will see TSM comparing the attributes of the file with
those currently on the TSM server. Go ahead and post the results and we'll
see what we can see.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 08/04/2004
08:08:03:

> Here is an example of what I am seeing.  I can't explain why it is
> backing up everything over and over and over again.  (fyi..The date
> April 28 is significant because the server was rebuilt on that day.)
>
> Ralph
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Andrew Raibeck
> Sent: August 04, 2004 10:12 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: archive attribute - windows 2000
>
>
> Do you have any tools that scan the machine on a weekly basis, and
> perhaps
> flip the archive flag?
>
> What I don't understand is how this could cause havoc with your
> incremental backup. TSM ignores the archive flag when determining
> whether
> the file has changed, nor does it change the flag after the backup
> (unless
> you use the RESETARCHIVEATTRIBUTE option).
>
> Regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Development
> Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> Internet e-mail: storman AT us.ibm DOT com
>
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 08/04/2004
> 06:56:48:
>
> > Has anyone seen a situation where the archive attribute gets turns on
> > but the data hasn't changed ?  I have a server that appears to have
> this
> > problem.  I don't see any scheduled tasks running that could cause
> this.
> > It happens weekly and causes havoc on my incremental.  I also see
> files
> > that have the attribute still on after the backup has ended (sometimes
> > the backup has to be cancelled because it bleeds into 1st shift.
> Could
> > that leave the attribute on?).  I am thinking about using
> > RESETARCHIVEATTR to see if this helps.  Any suggestions would be
> > welcome.  This is a windows 2000 server version 5 sp 4 build 2195 with
> > TSM client 5.1.7.
> >
> > Thanks,
> > Ralph
>
> [attachment "backup_prob.gif" deleted by Andrew Raibeck/Tucson/IBM]