Thanks, Richard, for pointing out the distinction. You are correct, on
Unix, regular incremental backup of normal directories does not include
the timestamp data as criteria.
On Windows, if the last write time for the directory has changed, then it
is a candidate for incremental backup. Create and access times are not
part of the criteria for incremental backup.
The FIOATTRIBS trace class can be used to help determine what TSM is
seeing as changed. If I were going to look at the trace, I'd want to add
POLICY and VERBINFO just so I can verify that the directories are not
being bound to a management class whose copygroup mode setting is
ABSOLUTE, in case FIOATTRIBS doesn't yield the answer.
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 2005-03-08
08:47:56:
> On Mar 8, 2005, at 10:16 AM, Andrew Raibeck wrote:
>
> > Hi Arnaud,
> >
> >> As Andy says it in his excellent web page : A normal Incremental
> >> Backup
> >> will *not* back up directories whose timestamp has changed since the
> >> last backup.
> >
> > This statement is wrong. I'm not certain you are referring to me (I
> > don't
> > have a web page) or another Andy, but it would help to know the
> > context of
> > this information. If the directory timestamp changes, I would expect
> > it to
> > be backed up.
> >
> > Try running "dsmc query backup" for the problem directories, and use
> > the
> > -detail and -dirsonly options. What does that output show? Do you see
> > any
> > differences in the timestamps?
>
> Hi, Andy -
>
> I think platform distinction makes a difference here...
> My experience (verified by experiment) is that Unix (AIX at least)
> directories do not get repeatedly backed up as their file complements
> change and their timestamps thus change. In the Unix environment, a
> directory timestamp is a trivial thing - too trivial to warrant another
> backup of the directory, where a restoral would be changing the
> directory timestamps anyway. In Windows, with its larger data set in
> the structure of the directory info, I can see that the directory would
> be backed up again when changes occur.
>
> In Unix, directories will likely get backed up afresh where the
> Incrbydate option is used, where there is no referential data for the
> client to consider when performing the backup. Another cause of
> directory backups in Unix is less common, and often "invisible": the
> use of Access Control Lists on the directory, as via the aclput
> command. (Using the -e option of the ls command makes the existence of
> the ACL apparent, where its contents can be listed via aclget.)
>
> Beyond that, I don't have an explanation for Arnaud's experience.
> Review of the file system area and the client backup log might yield
> clues.
>
> Richard Sims
|
