Hi Arnaud,
I inadvertently for get to mention to add the "-inactive" option to that
list, so you can see differences between all available versions.
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:53:09:
> 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
> > **********************************************************************
> > **
> > ******
|
