Good deal, if I ever have to restore 2.4tb again.. and I hope I don't have to
:) .. I'll do a saveset recover.. thanks..
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of George Sinclair
Sent: Monday, September 19, 2011 2:46 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] 2.4TB File Server Restore
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
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
|
