Netbackup migration from SPARC Solaris 10 to Intel Suse 11.1

[evo]

Hi All,

We are planning to migrate Netbackup 7.1.0.3 from SPARC Solaris 10 to Intel Suse 11.1. To do this, we are planning to install Suse 11.1 and Netbackup 7.1.0.3 to a new machine and just copy the catalog ( /usr/openv/db and /usr/openv/netbackup/db ) from SPARC Solaris 10 machine when netbackup is stopped on both machines.

Is that work?

Thank you.

[Yogesh9881]

This will NOT work !

You need to contact Symantec consultancy Services.

take a look on below URL.

http://www.symantec.com/business/support/index?page=content&id=TECH31385

[mph999]

Some links ...

http://www.symantec.com/docs/TECH155651

This TN shows a potential issue ...  http://www.symantec.com/docs/TECH183348

[marekkedzierski]

It will work. Remember to copy also /usr/openv/var/global, /usr/openv/netbackup/bp.conf, /usr/openv/volmgr/vm.conf. You have to use the same dns name on new master. 

[mph999]

No it won't - you'll only be able to run restores.  All the media DB info will be missing.

Martin

[mph999]

You can't just copy the catalog, but a Catalog recovery will work, as Unix > Linux should be OK.

Has to be same version, same hostname etc ...

The technote shows you cannot go from unix > windows (or vice versa).  It does not say you can't go from unix > linux.

Catalog recovery steps are in the toubleshooting guide.

Martin

[Marianne]

You can migrate using Hot Catalog Backup and restore. I have done the exact same thing for a customer a couple of months ago.

See this TN for details: http://www.symantec.com/docs/TECH77448

Using catalog backup and recovery to transfer NetBackup catalogs between UNIX or Linux master servers as part of a hardware refresh

[Yogesh9881]

evo i really apologies !!

Dear martin thankx for correcting me 

[mph999]

No problem Yogesh, what can and cannot be done is not always very clear.

In nushell, Win to win works, unix to unix works, and as linux is same path type as unix unix > linux or linux > unix works as well.

Martin

[evo]

Thank you all for the answers.

It will be difficult for me to use catalog backup-recover method. Because our full catalog backup takes more than 12 hours to complete and catalog recovery will also take more than 12 hours. So I need to shutdown the backup system for more than 24 hours.

But if it is possible to use copy-paste method, I can copy the necessary files to new machine when Netbackup is working and then stop Netbackup services and copy the changed file since full copy.

Any idea?

Thank you

[Yogesh9881]

Ohhh really !!

"full catalog backup takes more than 12 hours"  -- what is catalog size ??

[evo]

Hi

Our catalog is 282GB. Not very big but full catalog backup takes more than 12 hours

[RonCaplinger]

Our catalog is also on a Solaris master, is currently at 462GB, writing to disk storage unit over a gigabit link, and takes about 3 hours.  Are you perhaps writing directly to tape? 

[mph999]

Potentially you can copy across /usr/openv/netbackup/db/images, but you are then talking about copying the changed files - what about the EMM database, you can't just copy across bits of this.

The catalog restore copies across more than just the images DB and EMM DB, there are policies, and various config files.

Your proposed method will introduce catalog consistency errors, and other potential issues that could cause issues in the future, by which point it is too late and you are stuck with a system that could give you constant issues.

I see too many of these attempts gone wrong, and sometimes the consequencies are serious.  My personal view, is that it should be done by the book (ie. catalog recovery) or not at all.  12 hr catalog backup times, as you have pointed outis too long for you, so what would you do if you had a real failure ??

Much better is to have multiple masters, this way in the event of failure, you loose only part of the environment, and, recovery time is manageable.

However, you don't have that so what are the options.

A)

You could do as you suggest, but trying to copy across bits of the catalog is not going to be easy.  You have the problem of EMM being out of date for a start. Definately not supported if it goes wrong,  Do I recommend it - no.

B)

Restore a very recent catalog to the new server, this will bring across policies etc ...  Stop all backups on the live, copy across the images DB and then bring across an nbdb_backup -online output and restore  that to bring the images and EMM across in sync.  While this happens NO backups can happen on the current live server.  Would this be supported, probably not.  Have I tested it, no, Do I recommend it no.

C) Do it the supported way - catalog restore.  Explain to your management this is how it is, as you have a large system and no on e considered the implications of having a large system (by this I mean catalog).

D)

Run a catlog arcive (see the admin guide for details),  This will backup the .f files and delete them.  The catalog will become 'tiny'.

Run a catalog backup - having stopped all backups.

Recover this as per a catalog recovery on the new system.

Unarchive the catalog

D) is your best bet.

Regards,

Martin

[Yogesh9881]

In continuation of martins excellent post.....

First let us know why 12 hrs for 280GB ?? need to work on this ....

after that run NBCC on existing catalog & clear all conflicts...

then perform full catalog backup on tape. & then go ahead

[Marianne]

evo, where are you backing up to? Locally to master's own disk or tape? Or over the network to media server disk or tape?

Have you ever tried to find the reason for slow backup?
Slow read speed from disk or slow write to destination? 
If you backup to SAN disk and reason for slow backup is slow read speed, the restore from SAN disk on new server could potentially be a lot faster than the backup.

Another approach would be to perform migration in 2 steps: 

Day 1: Do full catalog backup on Solaris master.  Start catalog restore on Linux server while Solaris master carries on with normal operation.

Day 2: Stop all backups on Solaris master. Do incremental backup. Restore incremental backup on Linux server.

You could also do the above as a test run to check timing and perform the actual migration a week later.
 

[GnuubBackupAdmi]

Evo,

Have you considered AIR (Automatic Image Replication) to the new box?  In essence it is "suppose" to be a turn key solution for DR of your Backup Domain.  I have my cup of kool-aid but I haven't drunk it yet...

So in theory you could AIR over to the SuSE box; take a maintenance stopping all jobs from running and AIR to sync up changes; then turnkey the backups to the new SuSE box.  I would image you would need to script out a bpsetconfig to update the server list on each client for the new SuSE box.

Or you could AIR over, shutdown NBU, AIR the changes to sync up; then let the SuSE box assume the identity of the Solaris box if your intent was to keep the same Name/IP (Mileage will vary with this hack).

Again, this would be in theory to cut you over and minimize the amount of maintenance you would take.  A test run wouldn't actually impact your current Solaris master.  Any detailed questions on AIR should be consulted with your TC.

[evo]

Marianne,

I am backing up the catalog to tape, which is SAN attached to master server and our catalog disk is on IBM XIV storage. I think, the reason of slow backup is that, there are a lot of small files in the catalog. Do you have an idea to speed up the catalog backup?

I will try to use 2 step migration method. But when I restore the catalog to new machine to test the timing, is there a negative impact on working master server?

By the way, you said that, you did exactly the same migration a few months ago. During migration, did have any issue, any error or anything important that you would like to mention?

thank you.

[Kev_Lamb]

I successfully migrated my Master Servers from HP-UX 11.23 onto RHEL 5.6 using the Technote that Marrianne has responded with, I had no issues at all with bringing the catalog back in using the Wizard.

[marekkedzierski]

You can use rsync to synchronize /usr/openv/netbackup/db for example one day before planned migration and run rsync again during migration to synchronize only inc data.