That would be the easiest way. Make sure hosts are the same on both machines and they run the same OS type and then by coping over db things should be up rather quickly (after changing what will probably change like control port of jukebox on new server, perhaps device ordering and other small things).

but i will be copying over 7.2 files onto a 7.4 new install?

i'm not sure how the whole upgrade will work?

You can upgrade old server first and move updated db or install 7.2.2 on new server, move there db and fix settings and then upgrade it.

Check the Disaster & Recovery guide Page 34 and further "Moving a networker server"

In short

1) Make backup of CFI's and bootstrap from the server
2) Make a note of the SSID info
3) Install new server with same o.s. and networker version
3a) Disconnect old server from network
4) Same name and IP-address
5) Use MMRECOV to recover database info
6) NSRCK -L6 to rebuild the indexen
6) Rehost your server with POWERLINK
7) Upgrade to latest networker server

Message was edited by:
Antoine Schokker

Rather than using mmrecov to recover the files, has anyone tried just copying all the files from /nsr from old server to new server? Wouldn't that bring over the DB, indexes and all?

Isn't that what I have said? Yes, that has been done, but you are limited somewhat to the fact that you need to have compatible OS types between two servers. Obviously, host transfer will be required too. This is also the method which is officially not supported so you may think twice before you do it.

Sorry for my misunderstanding... Not knowing NetWorker very well or which host OS is being referenced, I wasn't sure what was specifically meant by moving/copying files. I was thinking in the literal sense in how this would exactly look like (ftp copying files, tape restore, secure FTP, etc.). I'm in a similar situation and looking to go from NetWorker 7.3.2 on Solaris 8 on a Sun Sparc server to NetWorker 7.5sp1 (why not jump to the latest, right?) on Solaris 10 on an new Sun AMD based server. OS is still Solaris, but I'm hoping that CPU architecture change won't bother it.

Ah, arch is playing crucial role here... check the story on big and small endians

I think it would work because issue with endians usually happens with index db if I remember correctly. There is a way to dump database to a file and to read it again back into db format, but usually this is done by EMC or EMC partner - otherwise it would be unsupported if you do it on your own. At least that's what used to be used in past. Itanium is really nice - as it can be both small and big endian

You're right. Given this, I don't think a file copy would work. I don't think even MMRECOVER would work, would it? Hmm... Maybe a file copy could work, assuming that the Solaris OS processes files in the same manner, regardless of the architecture. Ug. What a pain...