Good morning..... I picked one file from yesterday afternoon's backup that is consistently being backed up but not changing. I ran this command this morning:
dsmc incremental e:\Install\ShipNet\qrp\letter\Inv_sea2.qrp -traceflags=policy,fioattribs -tracefile=dsmc.trc It backed it up again. Here is trace file. Thanks again for taking the time to help. Ralph -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Raibeck Sent: August 04, 2004 12:53 PM To: [EMAIL PROTECTED] Subject: Re: archive attribute - windows 2000 Well, from the attached file, I saw the file was backed up only 5 or 6 times since May. I can't say *why* TSM has multiple backups of the file. Some possible reasons include: * incomplete -incrbydate backup. If you use -incrbydate, check the last backup time for the file system * selective backup * mode setting of ABSOLUTE instead of MODIFIED in the copy group * other non-obvious changes, such as security attributes or creation date (use "dir /tc some.file.name" to see the creation date) Have you tried testing backup of a single file, i.e.: dsmc incremental some.file.name and then immediately repeating the "dsmc incremental" command? Does it back the file up yet again? If so, you can try tracing the backup like this: dsmc incremental some.file.name -traceflags=policy,fioattribs -tracefile=dsmc.trc This will show you policy info where you can check the copy group modes. Below that, you will see TSM comparing the attributes of the file with those currently on the TSM server. Go ahead and post the results and we'll see what we can see. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> wrote on 08/04/2004 08:08:03: > Here is an example of what I am seeing. I can't explain why it is > backing up everything over and over and over again. (fyi..The date > April 28 is significant because the server was rebuilt on that day.) > > Ralph > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of > Andrew Raibeck > Sent: August 04, 2004 10:12 AM > To: [EMAIL PROTECTED] > Subject: Re: archive attribute - windows 2000 > > > Do you have any tools that scan the machine on a weekly basis, and > perhaps > flip the archive flag? > > What I don't understand is how this could cause havoc with your > incremental backup. TSM ignores the archive flag when determining > whether > the file has changed, nor does it change the flag after the backup > (unless > you use the RESETARCHIVEATTRIBUTE option). > > Regards, > > Andy > > Andy Raibeck > IBM Software Group > Tivoli Storage Manager Client Development > Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] > Internet e-mail: [EMAIL PROTECTED] > > 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" <[EMAIL PROTECTED]> wrote on 08/04/2004 > 06:56:48: > > > Has anyone seen a situation where the archive attribute gets turns on > > but the data hasn't changed ? I have a server that appears to have > this > > problem. I don't see any scheduled tasks running that could cause > this. > > It happens weekly and causes havoc on my incremental. I also see > files > > that have the attribute still on after the backup has ended (sometimes > > the backup has to be cancelled because it bleeds into 1st shift. > Could > > that leave the attribute on?). I am thinking about using > > RESETARCHIVEATTR to see if this helps. Any suggestions would be > > welcome. This is a windows 2000 server version 5 sp 4 build 2195 with > > TSM client 5.1.7. > > > > Thanks, > > Ralph > > [attachment "backup_prob.gif" deleted by Andrew Raibeck/Tucson/IBM]
dsmc.trc
Description: dsmc.trc
