Francis Swasey wrote:

I moved from 64-bit Solaris (Solaris 9) to 64-bit Linux (RHEL 5) in May of this year. I did not change versions (I was running 7.4.3 on both servers). I did not change host name or address.

My general process was to follow the DR guide (mmrecov) and then use nsradmin to make the changes to the (mostly) notifications paths for the OS differences. We contracted with Cambridge Computer Services (http://www.cambridgecomputer.com) for a procedure and a few hours of assistance.

It is most certainly possible to make the change from Solaris to Linux without having to scan (in my case) seven years worth of tapes -- despite what your EMC sales/support folks will tell you.

The /nsr/indexes directory is endian neutral and therefore is just an rsync from old server to new server to move it.

Thanks,

George

Frank

On 11/30/09 9:48 PM, George Sinclair wrote:

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

- 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