It may just be that the file had been updated between the end of the
previous incremental and the start of this one. Consequently it would be
flagged for backup when TSM builds its list.
By the time TSM gets around to backing an application or a person could
have amended the file again thus giving a time stamp later than the
initial TSM scan.

As long as the file is not changing at the point it gets backed up, i'm
guessing that you would see no error messages. I'm not sure if TSM would
know or bother to check if the files size/attributes had changed between
the initial scan and backup unless it found it open.
It knows its supposed to back it up and just does it.

Regards
John




"Thomas Denier" <Thomas.Denier AT MAIL.TJU DOT EDU>

Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
08-Nov-2002 17:34
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>




        To:     ADSM-L

        cc:
        Subject:        Re: Backup Question

> Zoltan,
> Thanks for your reply, but here's what I thought:
> After it builds a list of files to backup, it then traverses/sweeps the
> tree(File System) to do the actual backup. At this time if it finds a
> new file in its path, it will back it up. If the file is placed in that
> path after TSM has gone past that File System Structure it will not go
> back to back it up since it has no knowledge of that file.
> The reason for my explaination is that we have seen many files whose
> modified time is much later than the Backup Start time and it is still
> backed up.
> Let me know your thoughts.

TSM clients from 3.7 onward have been designed to overlap the later
part of the file scan with transfer of new and changed files found in
the earlier part of the scan. On a lot of our clients the time stamps
in the log indicate that the scan stretches out over most of the duration
of the backup. With that kind of timing behavior the scan might pick up
files created toward the end of the backup, depending on the location
of the files.