Migrate 6.5.3 from Solaris to RedHat - error 277

[PrisonPlanet88]

We, are migrating off of our Sun server to RedHat for obvious reasons...disk space, performance, maintenance cost savings etc.

Our current Config is:
* Solaris 9
* Netbackup 6.5.3 w/ Vault
* Fiber attached TLD Sl500 robot w 5 sDLT drives
* Unit is Master / Media combined

This is a step by step on what I've done to migrate:

* Built the new server up with RedHat 5.3 2.6 kernel
* Downloaded 6.5, installed
* Patched to 6.5.3
* Stopped nb daemons on the Sun box
* Fired up NB on the new server
* configured robot and drives through the admin console wizard.
* Stopped NB on the NEW server
* Started NB up on the Sun box
* Performed a Hot catalog backup FULL to tape
* the Catalog generated its email and was sent to me with the file atached
* Stopped NB on the old server, started up the NEW server
* Coppied over the recovery file from the old server to the new one.
* Ran through the steps from the catalog recovery procedure email on the NEW server
*  Ran bpimport -create_db_info [-server name] -id 501828 sucesfully
* Ran bpimport [-server name] -backupid fwstnb1_1247150827 sucessfully
* Ran -T -w [-L progress_log] -C fwstnb1 -t 35 -p NBU-Catalog-Hot -X -s 1247150827 -e 1247150827 /

Received an EXIT STATUS 227: no entity was found.

I also ran the catalog restore from thr GUI wizard, and it received the same result. Both servers have the same hostname. My question is, is this a practical way? is there a doc on migrating from one flavor of UNIX to another? Is there an answer to my error? 

Thanks is advance.

-Mike

[Abesama]

NetBackup has Sybase ASA database built in EMM, which may or may not like being suddely moved to a new operating system. (Yet to test it myself, I will get a chance to try it myself very soon)

Within my knowledge I am not aware of any such document for NetBackup master migration across different OS.

But... 227 after a successful import phase 1 and phse 2 ... very strange, because 227 comes from bpdbm, not EMM. (If I'm wrong, please correct me, anyone) and a successful import means a successful bpdbm operation. (images DB)

By "Ran -T -w [- ..." you mean you ran "bprestore" right?

Did you check the progress log from the restore, or the bpdbm debug log?

What I can think of is "double-double-check your hosts file, resolv.conf file, SERVER entries and required_interface entry and client_name entry in bp.conf" because, it is possible that the bpdbm is failing to query the image database.

Touching /usr/openv/netbackup/db/altnames/No.Restrictions, if done with enough cautions, may help too.

Good luck mate, and plz keep all of us informed if you get any progress.

Abe

[Mouse]

Recently we tried to perform a trick with a migration from Windows 32-bit to 64-bit using the same way.
We failed with some problems with EMM and after that we have logged a case with support.

Surprisingly, they closed the case with this reference: support.veritas.com/docs/267137

So, they gently asked us to pay for Symantec Consulting to do this otherwise they cannot help us.

[PrisonPlanet88]

-Yes, I ran bprestore...sorry typo.

Support Call

I also opened a service call with symantec. They told me to the same, that I had to get with Symantec Consulting...

With vault running, working in a production time, my window for trying to migrate this is slim.

Abesama, I will try the suggestion you made today and see if that helps any..I would love to get this going. About the bp.conf, my next step was to go through it. I will let you know if we make any progress and try to post the bpdbm log soon.

-mike

[PrisonPlanet88 · Accepted solution]

Migration a success!

After moving the host files over from the old server and replicating paramaters from bp.conf onto the new server. We are up and running. I ran another full catalog backup and used the GUI catalog recovery interface and ran another fulll recovery from a Full catalog backup. I ran some test backups, and they launched fine. We dont use DNS on our backup segment so I we had to change the client host files to point to the new server, since the IP address did change.
 
The only issue im weeding out at the mement is that it thinks we have more drives in use in the robot that are not. The robot likely needs a reboot to perform a complete inventory.

Thanks for all of the help, a true test will be tonight. Although the migration was a success I am anticipating some issues. Not going to close the thread just yet!