Andy,
I tried to activate the traceflag FIOATTRIBS, however to simulate the
same conditions as usual, I had to issue an incremental backup command
without specifying any object : the output was huge ! I then tried to
understand it, and found out that only the objects having "Mod Time
different: returning ATTRIBS_BACKUP" where eligible for backup,
unfortunately none of those objects was my "/export/mksysb".
However I found something strange, looking like this :
========================================
09.03.2005 16:37:06.860 : unxfilio.cpp (1449): fioCmpAttribs:
Attribute comparison of two files
Attribute Old New
--------- --- ---
ctime 1110357049 1110360549
mtime 1110357049 1110360549
atime 1110357026 1110357744
File mode OCT 242755 242755
uid 3 3
gid 3 3
size 1024 1024
ACL size 0 0
ACL checksum 0 0
inode 2 2
09.03.2005 16:37:06.860 : fileio.cpp (4735): fioCmpAttribs():
old attrib's data from build (IBM TSM 5.2.3.1)
09.03.2005 16:37:06.860 : unxfilio.cpp (1488): -->Mod Time
different: returning ATTRIBS_BACKUP
===============================================
09.03.2005 16:37:06.877 : incrdrv.cpp (9567): Incremental attrib
compare for: /export/mksysb/lost+found
09.03.2005 16:37:06.878 : unxfilio.cpp (1393): fioCmpAttribs:
Attribute comparison of
two directories
Attribute Old New
--------- --- ---
File mode 82424 82424
uid 0 0
gid 0 0
ACL size 0 0
ACL checksum 0 0
09.03.2005 16:37:06.878 : fileio.cpp (4735): fioCmpAttribs():
old attrib's data from build (IBM TSM 5.2.3.1)
09.03.2005 16:37:06.878 : unxfilio.cpp (1434): -->Attribs equal:
returning ATTRIBS_EQUAL
It looks like "something" is eligible for backup, which is the first
object in the series concerning the contents of /export/mksysb, but the
trace doesn't name it ?!
Also, something comes to my mind, which may be important : this
/export/mksysb is not a subdirectory from /export, but the mount point
for a filesystem, could that have any impact ?
Thanks for your answers, and take your time for responding : night is
coming in Switzerland, and I'm living the office till tomorrow ...
Cheers.
Arnaud
************************************************************************
******
Panalpina Management Ltd., Basle, Switzerland, CIT Department
Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.brion AT panalpina DOT com
************************************************************************
******
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Andrew Raibeck
Sent: Tuesday, 08 March, 2005 20:15
To: ADSM-L AT VM.MARIST DOT EDU
Subject: SUSPECT: (MSW) Re: Directory path backed up again and again ...
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
|
