|
Re: [Networker] 2.4TB File Server Restore
2011-09-19 15:47:04
On 2011-09-19 14:05, Chester Martin wrote:
The odd thing is that I wrote the data to a new lun, the data was restored from "E:" and
restored to "I:". It asking for an overwrite threw me for a loop, it was actually in the
first few hours of the restore. In this case I wasn't worried about any old files showing back up.
That is odd. Have no answer, but perhaps it's something specific with
Windows or data domain. I have seen cases where Windows OS did not
preserve time stamps when copying directories but did on the constituent
files, not that that should impact NW but ...
I'm guessing with the save set recover I would've had to do three separate
restore jobs starting with the full.
That's how I would do it, if I were going to go the save set recover
route. So, I'd start with the full then move to the first incremental
after that and finally the second (last) one, with the last being the
most recent for that save set - so basically in the order that you would
have expected NW to have loaded them (never mind whether it did or not),
but in this case you'd have to run each save set recover separately (one
at a time) since each has its own unique ssid. You could script it, of
course, and turn on the option for automatic overwrite, figuring that
you could very well encounter previously recovered files, but if you're
going in the order from oldest save set instance to newest then it seems
logical that you would want to overwrite an older recovered version of a
given file with a newer copy that was, say for example, captured on a
subsequent incremental.
Alternatively, you could launch one recover at a time and answer 'y' for
each (possibly long and tedious) or just 'Y' one time for that given
recover operation and then continue on to the next.
I suppose it would be *possible* to actually recover all three pieces to
separate locations, assuming three different tapes, (and three available
tape drives) since they wouldn't step on each other, but then you'd need
a way to merge the results and remove duplicates. That might be tricky,
but if you could figure it out, it might save time, depending on the
size of the incrementals. I'm sure people have done this, but I'm not
advocating it as a general solution, only perhaps for a special case
scenario.
George
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of George Sinclair
Sent: Monday, September 19, 2011 11:17 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] 2.4TB File Server Restore
On 2011-09-19 09:55, Chester Martin wrote:
Hello,
This past weekend I had to do a 2.4Tb windows cluster data restore from data
domain, it amounted to a little over 1 million files. It came from a full
(Tuesday) and two incrementals (Wednesday and Thursday) for the one restore.
I ran the restore from the command line because I "thought" that it wouldn't take as long for networker to
"select" the files that it had to restore. It took almost 5 hours for networker to "select" the
files that it had to restore. By select I mean that it shows the directories that it has to restore when you type in
the "add *" command.
Good thing is, while the files were being restored it actually showed the progress of
each file being restored from the command line. I know the gui does this but sometimes
when you're restoring a lot of small files the gui will "hang" and show nothing
but a white screen (gotta love the single threaded apps.. :)).
The odd thing that networker did was it restored the incremental from Wednesday first (I
could tell by the size of the saveset being restored). It also prompted for overwrite,
which is odd because I restored all the data to a new freshly formatted volume. After I
gave it a "Y" Wednesday's incremental completed then it started writing data
from Tuesday's full, then Thursday's incremental. The whole thing completed successfully
yesterday afternoon.
I have two questions from it though:
1) Could I have done a "save set" restore and the gotten around the
initial 5 hours it took to select the restorable data? That part was painful to wait
for..
A save set recover is often faster as it doesn't have to read the CFI.
Reading the CFI, particularly that many entries, is going to take a long time.
The problem with a save set recover, however, is that it restores deleted
files, and you'll need to tell it whether or not to overwrite.
With browsable recover it rebuilds the affected path the way it looked as of
that backup date/time so anything that was subsequently deleted would not be
restored. Also, with a save set recover you'd have to do each piece, and you
still might end up with a superset of the files. Any time you have a huge
recovery to do wherein the total amount of data that's to be restored comes
close to the total size of the full then I'd be looking seriously at just doing
a save set recover. It would depend, of course, on your situation and how
important it is to you to have an exact rebuild.
2) I'm still unsure why I got an overwrite prompt when it restored all
the data to a new volume, is that normal?
If there was no prior identical named file/path(s) existing then I don't see
why it would have prompted you. It should only be doing that if it encounters
such a situation. As far as the order of the tapes is concerned, I think NW
**may** have changed the behavior at some point???
My experience was that it always started with the full and then worked forward
(in time), beginning with the next incremental and continuing with every
incremental after that up to and including the most recent one that would
contain the needed files. That was how it always worked, but I noticed with a
newer release that it will work backwards. I've seen it wherein it starts with,
say, the full and then applies the incrementals in some different order. But in
the end, I don't think it matters. If it goes forward then it would overwrite
similar named files as it encounters subsequent (newer) versions. If it goes
backward then it would just not recover or not overwrite the previously
recovered version with the older one. It seems that going backwards would be
more efficient, but that's just a guess. I'd be curious to see what others have
to say about this.
How long after starting the recover did it prompt for overwrite? Was it at the
beginning or part way through?
George
Thanks in advance.
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
Voice: (301) 713-3284 x210
- The preceding message is personal and does not reflect any official or
unofficial position of the United States Department of Commerce -
- 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
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
Voice: (301) 713-3284 x210
- The preceding message is personal and does not reflect any official or
unofficial position of the United States Department of Commerce -
- 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
|
|
|
