Networker

Re: [Networker] NetWorker oddity - is it me or just the way it works?

2008-10-08 11:17:19
Subject: Re: [Networker] NetWorker oddity - is it me or just the way it works?
From: George Sinclair <George.Sinclair AT NOAA DOT GOV>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Wed, 8 Oct 2008 11:14:56 -0400
James Pratt wrote:
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
On Behalf Of George Sinclair
Sent: Wednesday, October 08, 2008 10:32 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] NetWorker oddity - is it me or just the way it
works?
This isn't really a question but more of an observation, really. I
guess
I'd just like to hear what others have to say on this matter. I'm not
suggesting that this is news to anyone, but I really hadn't ever
thought
about this before until I did some testing recently. I think this is
present in all NW versions, and it's simply the nature of the beast,
good or bad. No biggie, really, just want to make sure that I'm not
misunderstanding something.

OBSERVATION
By default, when NetWorker runs incrementals, it will back up any file
whose file status time has changed or is newer than the last time
incrementals ran. I know that that behavior can be changed to only use
mod time, via directives, but otherwise, it's file status time. And
file
status time obviously includes more than just mod time changes like
you
would expect when a file is modified or newly created. So, for
example,
changes to the permissions, ownership, group, etc. would also force a
file status time change (ls -lc), even if reset to the same value. A
more subtle change, however, would be when moving a file from one
location to another, which also resets the file status time and thus
would force a backup. BUT, let's suppose someone renames a directory.
In
this case, the directory's file status time (ls -lc) would change, BUT
the constituent files would still retain their previous times (not
just
mod times, but file status times also). As a result, if an incremental
was run, only the pathname to the directory would be backed up and not
the files. I've tested this, and that's the case. Only a full, numeric
or running a manual incremental from the client, and specifying an
older
date, will force those files to get backed up, unless of course you
affect a file status time change on them, e.g. 'chmod -R u+r dirname'.
So NW just sees the times and rather than noticing that the files are
now in different locations (different paths), it just ignores them
since
they're not newer than the previous incremental.

PROBLEM
This seems like a potential gotcha because if a user renames a
directory, and then deletes the data, say a week later, and then you
go
to recover the directory from that incremental then all you'd recover
would be the directory name. You'd have to go back further to get the
files, but how would you know where to find them since they were last
backed up under a different directory name??? Obviously, you could
loop
through all the save sets (say over the last month) for the parent
file
system using 'nsrinfo -s server -t nsavetime client' and grep for one
of
the file names to determine which directory contained it, or you could
just browse around one day at a time, or some such thing, but it
sounds
like the only real answer to this is to expect the user to provide
more
info to clue you in as to the fact that the data had previously lived
under another directory?

Does this make any sense? Any comments?

Thanks.

George

Interesting - I never knew this. A better question to me would be, why
doesn't networker see the directory name change(s) as a "new" file/dir
and just back it all up again "fresh"? That would seem proper, and would
avoid the above problem, correct?.... I cannot think of any adverse
side-effects of that behavior, so now I am curious what making new extra
subdirectories and such would reflect using such tests? (then again, I'm
no nw expert either!) ;)

Well, it certainly does see any newly created files, or directory names or modified files, but my observation is that it ignores files whose file status times are not newer, even if they've been moved. When a file's mod time changes, so does its file status time, but not necessarily vice versa. Now obviously, moving these to another server, or another file system on the same server, would affect those times, however, since that's a copy and not an actual (atomic) move. Ditto for recovered data (tar, unzip, NW recover, whatever ...) as the file status times will be the time that the file was written to disk even though its mod time may be older (original).

Perhaps, though, I'm just mistaken about this oddity?, but that's what I've noticed. One bad thing about just backing it all up again is that it could create huge incrementals in a case where there were a lot of files whose file status times hadn't changed. I'd be curious to see if others observe the same behavior? Could someone test this?

George


Regards,
jamie

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER



--
George Sinclair
NOAA/NESDIS/National Oceanographic Data Center
SSMC3 E/OC3 Room 4145         | Voice: (301) 713-3284 x210
1315 East West Highway        | Fax:   (301) 713-3301
Silver Spring, MD 20910-3282  | Web Site:  http://www.nodc.noaa.gov/
- Any opinions expressed in this message are NOT those of the US Govt. -

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER