Ok, lots of helpful hints about recovering a whole networker
installation - definitely something we should all have hashed out - but
I see you can only get at whats in the lto-3 tapes only.. And in fact
you want just one saveset...
So, in the manpage for scanner there's a technique for extracting a
saveset to stdout and piping that into the uasm command.
That's in theory the absolute shortest restore time... If it was on one
tape, but with multiple tapes you have to hang around to swap tapes
also.
With lto-3, restores to a local system can stream at something more than
63MB/sec.. With a text based load you may need to support a restore
speed of 150MB/sec or more if you are to get the drive running at full
speed, so pay attention to the filesystem you are restoring to... An
unmirrored stripe of 5 sata disks will do it... If you do get the
restore going at 150MB/sec that's only about 2 hours you have to wait
around...
Having a down-and-dirty procedure like this means you need some info up
front about which tapes to take, and the ssid you want to restore - you
could start out by scheduling a mminfo query each time the big backup
finishes and have it put somewhere safe - eg email it to another site,
or a printout, or gmail etc..
* get a report like this, modify the query however you see fit of
course, this example assumes theres only one clone of the saveset, and
one full backup a day, and nothing failed or got retried...
mminfo -xc, -q 'savetime>1 day ago,client=blah,name=/usr/bigtext' -r
fragflags,volume,ssid,mediafile,mediarec |grep -v volume|sort
This may be quite a long report - one line for each fragment - in your
case this will probably be one fragment per tape as its just the one
client in that pool and so maybe only 2 or 3 lines...
Anyway the fragflags are at the beginning of the line so it can be
sorted by them (hb=head, mb=middle, tb=tail) The fragment shown as hb
is the first one... This gives you a list of tapes to take with you
and the order they will need to be scanned..
Put the first tape in the drive...
To restore the saveset to the path /newpath Run this:
scanner -f {mediafile} -r {mediarec} -S {ssid from report} /dev/nrst0
| uasm -rv -m /orig=/newpath
Where mediafile and mediarec are the offset into the tape of the first
fragment - this is optional but lets you fastforward to it - probably
wont help in your case as its probably the start of the tape anyway...
The scanner process will prompt for each tape and gives you a chance to
specify the mediafile and mediarec offset each time you change tapes...
There's probably a bit of tweaking you need here - you can at least try
this out on your linux storage node to perfect the process before you go
to sungard... Good luck...
> -----Original Message-----
> From: EMC NetWorker discussion
> [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On Behalf Of Stan Horwitz
> Sent: Thursday, 17 January 2008 1:24 AM
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: [Networker] Tips for doing a DR at SunGard
>
> Greetings everyone;
>
> I am scheduled to do a DR test at SunGard on January 27th. This is a
> first for me. I am told I will have an LTO-3 tape library
> connected to
> a Sun box with Solaris 10. My production NetWorker server is
> 7.4 on a
> Sun T2000 with Solaris 10. I am scheduled to recover data from only
> one client, a Linux box and I will have another Linux box at my
> disposal at SunGard for this exercise. I am heading over to
> SunGard in
> a couple of hours to do a pre-flight check, but they said they won't
> allow me to log onto any of the test hardware until the day of the
> test, which is not good from my standpoint. I also will not have the
> benefit of my production server's media database and CFI for this
> test. Fortunately, the data is all straight text files, no database
> stuff and its only one client; the one that handles our University's
> most important data. For this test, I also only need to recover a
> subset of the files in order to verify that they can be read,
> but I am
> going to try to talk the others on the DR team to let me recover the
> full set of data so I can get an idea of how long the recover
> process
> would take in a real DR situation. The entire set of data is roughly
> 1TB.
>
> Since I only have one client I need to recover, I am thinking
> I would
> just put the tapes in the SunGard tape library and start
> scanning them
> in order. For this particular client, I have an automated
> script that
> emails me daily the output of "mminfo -v " and I get that
> output both
> on my work email and my gmail.com address and I also automatically
> archive the results on a web site at work and on a google groups web
> site for safe keeping. I do the same for the daily bootstrap.
> Unfortunately, I do not have the means to do a test of this
> before the
> SunGard DR test; we lack the disk space.
>
> So if anyone has any tips on how I should go about doing this
> recover
> at SunGard, please let me know.
>
> Thanks
>
> --
> Stan Horwitz
> Temple University
> Enterprise Systems Group
> stan AT temple DOT edu
>
> CONFIDENTIALITY STATEMENT: The information contained in this e-mail,
> including attachments, is the confidential information of, and/or is
> the property of, Temple University. The information is intended for
> use solely by the individual or entity named in the e-mail.
> If you are
> not an intended recipient or you received this in error, then any
> review, printing, copying, or distribution of any such
> information is
> prohibited. Please notify the sender immediately by reply e-mail and
> then delete this e-mail from your system.
>
> 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
>
NOTICE
This e-mail and any attachments are confidential and may contain copyright
material of Macquarie Group Limited or third parties. If you are not the
intended recipient of this email you should not read, print, re-transmit, store
or act in reliance on this e-mail or any attachments, and should destroy all
copies of them. Macquarie Group Limited does not guarantee the integrity of any
emails or any attached files. The views or opinions expressed are the author's
own and may not reflect the views or opinions of Macquarie Group Limited.
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
|
