> -----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!) ;)
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
|
