Re: [Networker] NetWorker oddity - is it me or just the way it works?
2008-10-08 13:08:04
Roberta Gold wrote:
I just checked. Apparently, the documented limitation is no longer in
the release notes, but included in the Admin Guide for 7.4.1 on page 622
in the Troubleshooting section "Renamed directories and incremental
backups".
Thanks for your corroboration and input, Roberta.
Perhaps I knew of this phenomena sometime back, and it had simply
disappeared from my memory - it's funny how we learn something and then
think the experience (a good one in my case) is indelible, only to
relearn it later - but regardless, I guess I'll just have to keep it in
mind.
I think if someone needed to get something back (assuming it was still
in the index) then I'd simply have to rely on their memory and/or loop
through the save set instances, using 'nsrinfo', and grep for whatever
file name(s) they could recall. Then I'd know which save time to use for
recover or nwrecover. Or the user will simply have to shell out the path
names by rote. Hmm ...
George
This behavior has existed since at least NetWorker 5.x and it did get
us! I complained, but the best response I got from Legato was it has
been documented as a limitation in (I believe) the release notes of
all further releases of NetWorker. I guess EMC/Legato thinks users
that create millions of randomly named files by running their codes
should be able to remember the old pathnames to all those entries ...
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
--
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
--
Roberta Gold
Lawrence Livermore National Laboratory
ICC/HPSD - Security Technologies Group
gold11 AT llnl DOT gov
(925) 422-0167
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
|
|
|