Hi, moving an older 64-bit NW 7.2.2 Solaris server to Linux server with
different host name. For now, we're running in test mode on this new
server, so wanted to check the migration steps as I've listed below.
Also, I have several questions/concerns further down.
I've read through the disaster recovery guide (7.51) and looked though
old postings here, but I'm still confused, so I'd greatly appreciate any
help. We have way to many tapes to scan everything in, even rebuilding
indexes would be a gargantuan task.
Specifically, we've done a few full backup tests on the new server for
some existing/older clients, wherein I created the NSR client resources
from scratch, but we'd like to perform some recovery testing via saveset
recover and nwrecover from some volumes written on the old server. I'd
like to just play around with a few clients for now and then do a final
migration later once I know this all appears to be working.
BACKGROUND: First, we're not ready to go live yet, so I know we'll need
to redo everything once we're done testing and dedicate one day to
getting the media database and indexes re-migrated by COB that day,
Also, we would really prefer not to upgrade the old server. We'd like to
just leave it alone since an upgrade is one-way and we have little space
on there, and we'd like to be able to go back if we had to.
Alternatively, installing the same, older version on the new server
first, and then subsequently upgrading it, is not really an option
either. But the plan would be that after testing, we get the host
transfer from EMC, do the final migration and then shut down the old
server once we're ready to go live.
Also, I don't really care about any of the non-Legato nsr related data
on the old server. So, I anticipate making the old server a client of
the new server for maybe just one final full and that's it. I don't know
that we would even need the old server's index on the new server?
OLD HARDWARE: Old server (Solaris 9) uses two RH Linux snodes, each with
its own tape library (one STK LTO-3, the other a Quantum SDLT600). No
tape library directly attached to old server, so we use file type device
to back up server's bootstrap and index, and those are automatically
cloned to LTO-3 and staged (different clone pool) every two weeks to
LTO-3. The media database is very small (320 MB), and total indexes
(approx. 34 clients) are less than 25 GB.
NEW TEST HARDWARE: RHEL box (64-bit, Dell PowerEdge 1950) running 32-bit
NW 7.5SP1 with latest version of NMC. Way faster box, way more disk
space. This test server has a *different* host name and uses a Dell
PowerEdge R905 Linux snode (32-bit NW 7.5SSP1) with attached Dell LTO-4
tape library.
Since the old/new servers have different host names, we can have both up
and running NW at the same time. We would prefer not to change the host
name on the new server, however. Thus far, we've configured the LTO-4
library and backed up a few existing 7.x clients that are currently
being backed up by the old server by changing /nsr/res/servers on those
clients to list both servers and stopping/restarting client software.
Everything looks good so far.
<<< MIGRATION STEPS >>>>
On old server:
1. Obtain client id for server
mminfo -q 'savetime>yesterday,client=server' -r clientid | sort -u
2. Clone latest bootstrap to a new clone pool volume.
note: this will be the only save set on this clone volume.
note: this is kind of cheating because I know I should rerun a level
full of the bootstrap as: `savegrp -O -c server`, since the media
database will have changed since the last bootstrap, but I just wanted
to save time for this test. For the final migration, natch.
On new server:
3. Set up symbolic links locations for /nsr so the directory structure
is the same as the old server:
Old server: /nsr -> /disk2/nsr
/disk2 -> /0/disk2
note: /0 is the file system, and disk2 is a directory under /0.
New server: /nsr -> /opt/nsr
a. Shut down networker software on new server
b. `rm /nsr`
c. `mkdir /0; mkdir /0/disk2`
d. `cd /0/disk2; ln -s /opt/nsr nsr`
I'm not sure about this step, but I'd read somewhere that mmrecov will
not work if you don't preserve the nsr directory structure?
4. Restart NetWorker.
5. Remove NSR client entry for server. Recreate NSR client entry, giving
it same client id as old server.
6. Manually load clone volume from step 1 into device on new LTO-4
library and run:
mmrecov /dev/nst#
note: since this will be the only data on the tape there should be no
reason to enter starting rec/file numbers, just hit return?
7. Shut down NetWorker on new server. Rename /nsr/res to /nsr/res.org.
Rename /nsr/res.R to /nsr/res.
note: I guess /nsr/index will remain as is and /nsr/mm will be
overwritten? I don't really care about /nsr/mm because we've only run a
few test backups on the new server (just one tape), so I can always scan
that in later.
8. Restart NetWorker.
9. Recover a few client indexes as:
nsrck -L7 clientname -t date
Not sure if this will work due to the fact that these were from a
different server, but maybe step 5 will permit this? If so, it should
request volume containing last full and then latest level 9. Could just
have created level fulls of the indexes to begin with ('savegrp -O'),
but thought instead that this might be a good test to see if the new
server can use the media database? We're only recovering a few indexes
to test, anyway.
10. nsrck -X
QUESTIONS/CONCERNS:
1. It's my understanding that the media database is not endian neutral
so disaster recovery must be used, but the indexes are neutral so they
could be copied/rsynced. But I've read that it's recommended to still
recover from tape. That true? Guess it's a good test regardless. I know
EMC does not officially support OS platform migration, but others have
done this successfully ...
2. Most of our clients could conceivably start from scratch on the new
server, and we could always run 'nsrck -L7' to merge in older entries
later if need be, BUT we don't have a large number of clients, and the
total size of the indexes is rather small. Also, we do have a couple
that we absolutely will require maintaining the index and picking up
where we left off as soon as we go live - at least until we can run new
fulls on all their save sets - and those few clients have a large number
of very huge save sets with a long browse policy (most of the save sets
do not change very often), so it would take us two weeks to run fulls on
all that. As a result, we'd like to keep those indexes so we can run
fulls at our leisure.
3. Can we in fact use the recovered res directory? Will the mmrecov
re-create all our NSR client resources, group, schedules, etc? OR will
it be necessary to re-create all that manually and instead use only the
recovered media database?
If so, I *can* do that as I wouldn't have to recreate all that much for
some simple initial tests. I could finish re-creating everything in
probably a week, if necessary, and periodically repeat the above steps
to get the latest media database info. Obviously, if I have to do this
manually, though, then I guess 'nsrck -L7' won't work until I've
recreated at least one NSR client resource for each affected client.
4. Will the recovery of the res directory complain about jukebox/device
configurations that are not known to the new server?
Once we're live, we're planning to move the SDLT tape library to the new
snode, and reconfigure and then install NW 7.5SP1 on the other snode
running the LTO-3 library, but we can't do that until then since we
still need those for our production backups on the old server. We're not
so concerned about the LTO-3 library, however, since we can read those
tapes on the LTO-4 library.
5. What about the server license? Even though we have a different host
name on the new server, will it disable itself after we recover the old
media database? I can add a temporary enabler code? we cant do the host
transfer until after we've had a change to test more. I mean, once we do
that, we need to be ready to roll, and we're not there yet.
6. Should I expect an MD5 checksum listing of an index directory on the
old server to be the same as the recovered version on the new server?
Or, will NW modify the whole thing, making it moot to even compare them?
7. I was thinking to run both a media query and a save set query of the
whole database on the old server before the migration and compare this
with the same queries on the new server, following the recovery, but not
sure if spacing or other format issues might produce different results?
Also, now that I think about it, if I don't run a fresh full of the
media database (step 2) then I guess I can expect there to be
differences with the differences being whatever was backed up since the
last bootstrap?
Thanks!
George
--
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
|