Andy,
Really sorry for involving you ! I was thinking to Richard's web page.
Anyway, your response has clarified the situation, as you're the second
one which tells me this is a normal behaviour.
Now, for your demand :
q backup /export/mksysb/ -detail
Size Backup Date Mgmt Class A/I File
---- ----------- ---------- --- ----
1.024 B 07.03.2005 20:43:30 BACKUP_2_Y A /export/mksysb/
Modified: 07.03.2005 09:51:59 Accessed: 07.03.2005
01:00:57
q backup /export/mksysb/ -dirsonly -detail
Size Backup Date Mgmt Class A/I File
---- ----------- ---------- --- ----
1.024 B 07.03.2005 20:43:30 BACKUP_2_Y A /export/mksysb/
Modified: 07.03.2005 09:51:59 Accessed: 07.03.2005
01:00:57
No differences at all !
I just made a test : created a new file in a test directory
>ls -ld test
drwxr-sr-x 3 sys sys 512 Mar 08 16:08 test
> touch /test/test
> ls -ld test
drwxr-sr-x 3 sys sys 512 Mar 08 16:44 test
> dsmc i /test/
IBM Tivoli Storage Manager
Command Line Backup/Archive Client Interface - Version 5, Release 2,
Level 0.0
(c) Copyright by IBM Corporation and other(s) 1990, 2003. All Rights
Reserved.
Node Name: XXXXXXX
Session established with server ADSM-PAC: AIX-RS/6000
Server Version 5, Release 2, Level 2.1
Server date/time: 08.03.2005 16:46:00 Last access: 08.03.2005
16:08:24
Incremental backup of volume '/test/'
Normal File--> 0 /test/test [Sent]
Successful incremental backup of '/test/*'
Total number of objects inspected: 4
Total number of objects backed up: 1
Total number of objects updated: 0
Total number of objects rebound: 0
Total number of objects deleted: 0
Total number of objects expired: 0
Total number of objects failed: 0
Total number of bytes transferred: 0 B
Data transfer time: 0,00 sec
Network data transfer rate: 0,00 KB/sec
Aggregate data transfer rate: 0,00 KB/sec
Objects compressed by: 0%
Elapsed processing time: 00:00:04
It looks like the directory was not backed up, as it's timestamp has
changed !
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 16:17
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Directory path backed up again and again ...
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?
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
07:52:37:
> Hi *SM'ers,
>
> I recently found that one (surely others too) of our AIX clients was
> getting part of it's directory structure backed up everyday although
> it did not change, but can't find the reason why.
>
> 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.
>
> We're performing incremental backups, copymode used for this client is
> set to modified, so I can't understand what's happening ! The worse is
> that the mgmt-class having the longest retention period (retonly 768)
> in this domain is used for storing that data, so I end up with
> thousands (probably more if other servers are affected !) entries in
> TSM DB which are worthless.
>
> This in an example of what I get, using "show version" (snippet of it)
> on this server:
>
> /export/mksysb : / (MC: BACKUP_2_YEARS) Inactive, Inserted 01/07/05
> 20:51:51, Deactivated 01/10/05 20:37:15
> ObjId: 0.539953678, GroupMap 00000000, objType 0x01
>
> /export/mksysb : / (MC: BACKUP_2_YEARS) Inactive, Inserted 01/10/05
> 20:37:15, Deactivated 01/12/05 20:37:32
> ObjId: 0.541340571, GroupMap 00000000, objType 0x01
>
> /export/mksysb : / (MC: BACKUP_2_YEARS) Inactive, Inserted 01/12/05
> 20:37:32, Deactivated 01/14/05 20:37:16
> ObjId: 0.542636928, GroupMap 00000000, objType 0x01
>
> /export/mksysb : / (MC: BACKUP_2_YEARS) Inactive, Inserted 01/14/05
> 20:37:16, Deactivated 01/15/05 20:38:31
> ObjId: 0.544018035, GroupMap 00000000, objType 0x01
>
> /export/mksysb : / (MC: BACKUP_2_YEARS) Inactive, Inserted 01/15/05
> 20:38:31, Deactivated 01/16/05 20:38:29
> ObjId: 0.544640259, GroupMap 00000000, objType 0x01
>
> /export/mksysb : / (MC: BACKUP_2_YEARS) Inactive, Inserted 01/16/05
> 20:38:29, Deactivated 01/17/05 20:38:53
> ObjId: 0.545097616, GroupMap 00000000, objType 0x01
>
> This is a NIM server, where "MKSYSB" files from other servers are
> stored everyday, so the content of the directory is changing, but not
> it's structure.
>
> TSM server is at 5.2.2.1 on AIX 5.2, client is 5.2.3.1,on AIX 5.3
>
> Could someone tell me what is happening here, and how to avoid this ?
> TIA.
>
>
> 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
> **********************************************************************
> **
> ******
|
