Sorry for taking this thread onto a tangent, but this info may be useful
to some.

After doing some more tests this morning, I stand enlightened and
educated.  This thread is probably more information than the original
poster ever imagined he'd get :-)

I was wrong in saying that Networker doesn't consult the client on-line
indexes to get the mod times of files to determine whether they are
backed up or not.  It does appear to do just that.

However, I did discover what was getting me confused on this topic.  If
the inode modification time is prior to the -t argument to the save
command, the file won't get backed up (for incrementals).  This explains
the behavior we see on our Symmetrix BCV volumes.  This is at least the
behavior I see.  My explanation of the behavior is only my guess as to
why.

To test, I did this:

Time    Action
------------------------------------------------
12:00:  Perform a full backup of save set XYZ

12:03:  Edit a file named ABC which belongs to save set XYZ

12:10:  Perform an incremental backup of save set XYZ.  Verified that
        file ABC got backed up during incremental.

12:11:  Changed time on server to be 12:07 using the "date" command.

12:11:  While the system thinks its 12:07, edited and saved file ABC

12:12:  Changed time on server back to 12:12.

12:13:  Perform an incremental backup of save set XYZ.  File ABC
        did not get backed up.

12:15:  Checked various times on file ABC, here is what they were:
           Mod time: 12:07
           Access time: 12:07
           inode mod time: 12:07 (do "ls -alct" to see this)

Note that file ABC, when it was backed up at 12:10, had a modification
time of 12:03, and when the next incremental backup ran at 12:13, file
ABC had a modification time of 12:07.  Even though the modification time
on disk was different and newer than what was in the client on-line
index (and thus, the file should have been backed up at 12:13), file ABC
didn't get backed up.

I also ran the above tests, except instead of changing the system time
with "date", I edited file ABC, saved it, and then used the touch
command (with the -m and -a arguments) to change the file modification
time, and the file was backed up as it should have been.

I've tested this on Solaris and HP-UX clients (6.1.3) with a HP-UX
server (6.1.3).

Also note that I changed the server time rather than simply using
"touch" to change modification times because the touch command can't
modify the inode modification time.  The inode modification time can't
be manipulated - its set to the system time when the inode was last
modified - you can't change it to anything you like, at least not with
touch.

For any normal system, you are not going to run into this problem.  Its
when you do fun stuff with BCV volumes that this can bite you.



On Wed, 2004-04-14 at 13:01, Ed Skolnik wrote:
> I beg to disagreed with you. Per Legato support "What I have to determine if 
> this is by design (as I mentioned before an incremental
> backup looks at client file index to see what was backed up during a full) or 
> if this a code defect or possibly an incorrect error
> message being generated.
>  "
>
> -----Original Message-----
> From: Craig Ruefenacht [mailto:craig.ruefenacht AT us.usana DOT com]
> Sent: Wednesday, April 14, 2004 11:43 AM
> To: Legato NetWorker discussion; Ed Skolnik
> Subject: Re: [Networker] FW: Incremantal backups in Legato Networker 6.1.4
>
>
> I hate to disagree, but, from the man page of Legato's "save" command (the 
> command that does the actual save):
>
>   -t date
>       The date (in nsr_getdate(3) format) by which files must have
>       been modified for them to be saved.  This option is used by
>       savegrp(8) and savefs(8) to perform scheduled saves by
>       consulting with the media database to determine the appropriate
>       time value based on the previous saves for the save set and the
>       level of the scheduled save.
>
> This is consistent from my post yesterday in this thread, as well as some 
> posts I made late in 2003 about this (search the mailing
> list archives for subject "determing what files to backup based on 
> modification times" for a in-depth explanation).  This almost bit
> us because of our setup of using BCV volumes with an EMC Symmetrix and the 
> timing of our backups in relation to when the BCV volumes
> were split.
>
> Legato backups all files that have a modification time that is more recent 
> than the "-t <date>" argument to the save command (for
> incremental saves).  Its as simple as that.  Legato doesn't do a comparison 
> of each file's actual mod time to the mod time of each
> file in the on-line indexes.
>
> This is for Networker 6.1.x, HP-UX server, HP-UX/Solaris/Linux clients.
> It may be different for Microsoft Windows and Novell (we do backup Windows 
> and Novell, but haven't had the need to experiment to
> find out how it behaves in those cases).

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=