Hey ...
I've been having discussions with EMC around this for a little while now
(we are seeing it in a windows environment - got to admit that I haven't
tested it on any Solaris / Linux servers) we see exactly the problem
that George is describing (also includes directory moves) , if we are
performing backups using VSS, if we use the change journal then I
believe it works, well it effectively performs a full backup of the path
structure below the directory that has changed. I have heard from
someone in support that this problem was fixed in Netware a few versions
back, but it remained in other client versions, and I think it had to do
with the fact that NetWare had a more extensive attribute list that
Networker could use to determine if files needed to be backed up ...
my main concern around this problem is in a DR scenario
directory c:\x contains file a.doc and b.doc
user renamed directory c:\x to c:\y
user creates a file c:\y\test.doc
a train crashes into my data centre destroying my file server,
and narrowly missing my backup server and tape library (phew!!!)
the server gets rebuilt, I go to recover all the data, tick the
little box next to C:\ and recover everything ... but alas the files
c:\y\a.doc and c:\y\b.doc don't get recovered and I am very sad :(
the good news is that apparently there is an interim fix coming in 7.5 -
apparently later this year ... but it will include some kind of
performance hit if you want to automatically back the data up or at
least some kind of notification and they are re-writing the file broker
in 8 but who knows when that little beast will be out
Mat.
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of George Sinclair
Sent: Thursday, 9 October 2008 6:28 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] NetWorker oddity - is it me or just the way it
works?
A Darren Dunham wrote:
> On Wed, Oct 08, 2008 at 11:14:56AM -0400, George Sinclair wrote:
>> 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).
>
> Right. The only way around this is for the client to have more
> information than just the timestamp of the last backup (or last
relevant
> backup) and the timestamp(s) of the file.
>
> Without the client seeing the whole index, it can't know that there's
> any reason to transmit the data about the files present back to the
> server.
>
Darren, that's a good point, albeit and obvious one that I hadn't
considered. Maybe I thought that the server could somehow relay this
information to the clients, or that they could peer into that index
remotely? I guess if that was the case then backups would take
considerably longer, and/or the information (meta-data) would have to be
stored on the clients for a certain period of time, making the whole
operation far more complex and potentially precarious. Either way, it
sounds like the way it *actually* works expedites the backup process or
at least the amount of time it takes it to figure out what to back up by
not having to do all that homework and just keeping things simple.
Otherwise, we'd be waiting a lot longer for backups to complete [sigh].
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
********************************* DISCLAIMER *********************************
The information contained in the above e-mail message or messages (which
includes any attachments) is confidential and may be legally privileged. It is
intended only for the use of the person or entity to which it is addressed. If
you are not the addressee any form of disclosure, copying, modification,
distribution or any action taken or omitted in reliance on the information is
unauthorised. Opinions contained in the message(s) do not necessarily reflect
the opinions of the Queensland Government and its authorities. If you received
this communication in error, please notify the sender immediately and delete it
from your computer system network.
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
|
