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.
I'm guessing with the save set recover I would've had to do three separate
restore jobs starting with the full.
-----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
|
