cancel
Showing results for 
Search instead for 
Did you mean: 

DR scenario will recover most everything, but not *db

jim_dalton
Level 6

HI Folks

Im thinking this is a NB bug but anyway theres a lot of folks in the forum with experience that may be able to shed some light.

Scenario: Sol10 Sparc master, NB7504.

Some other media servers, including a Windows box in the DR site.

Also at DR site: Sol10 x86 DR master server, shut down most of the time.

Previously tested: catalog written by Sol10 sparc master recovered onto Sol10 x86 master in DR. No problems.

Both masters have the same name.

However as above I've got a media server (the Windows box) at my DR site and I've configged a policy to write the catalog to that. And now I'm testing it.

I've got my override to tell it that it needs to not use the original media server: FORCE_RESTORE_MEDIA_SERVER = <originalwindowsmediaserver> Solx86master

And the restore runs almost the whole way through...I get my catalog...clean as a whistle.

But right at the end I have issues:

It wont restore anything from /usr/openv/db/staging eg BMRDB, BMRDATA , (the kind of stuff you need at DR!) , theres maybe 20 files it refuses to deal with.

Then it gives error 2850  and thence

Failed to recover NBDB on <server> (5)

Thence unable to freeze media 000039 server name not found in Netbackup config (254)

If I repeat the exercise the result is slightly different:

Immediately the DR recovery tells me some utterly confusing message about 'these files will not be restored because they are not present when the backup- was done" (which is incorrect) then again it lists the contents of .../db/staging as it did the first attempt saying

.../staging/BMRDB.db is not in the true image list.Skipping.

etc

It then recovers the catalog and then repeats the  business of everything in .../db/staging were not restored.

My feeling is that whilst it  does the restore, it restores bp.conf, and when it has done that, it no longer has  the FORCE_RESTORE_MEDIA_SERVER entry for the media servers I no longer have..so that act of the restore causes the restore of the staging data to fail.

bp.conf has changed, it is the one from the master, timestamp 15:25 and the error occurs at...you guessed it:15:25:43

So I need FORCE_  etc in the original bp.conf on the backup, BUT I dont want to do that when restoring, only in DR.I want to restore using the server that did the backup for speed.

Thoughts?

Thanks in advance,Jim

 

8 REPLIES 8

mph999
Level 6
Employee Accredited

You have the correct solution, the bp.conf is overwritten.

You see pretty much the same issue when a catalog recovery is done onf a OST/ Advanced Disk - that has a different 'internal address' to when the catalog was taken.

No way round it automatically (apart from to resotore catalog ) from original server (master is good for this reason).

Only thing I can think of

1) is to let it fail, then re-run bprecover -nbdb with the FORCE_RESTORE put back, or 

2)

Recover the NBDB files via browsing that catalog image , stick in the staging area

Run nbdb_restore to recover the DB

(Note 2) is unsupported .... but should work as the only info you need for the are the images header/ .f files which I think you have recovered.

Martin

jim_dalton
Level 6

tx for input mph999...if I put the FORCE_RESTORE_ in the production bp.conf it should fix the problem I reckon, I will test it tomorrow. I'd rather have DR fixed given a choice.

js88699
Level 5
Partner

Maybe a dumb idea, but can you just drill down and uncheck the bp.conf file from getting restored?

 

Mark_Solutions
Level 6
Partner Accredited Certified

Once it fails edit your restored bp.conf and then run bprecover -r nbdb and see if that does the trick for you

It is a little like when a copy 2 gets used and causes similar issues

Marianne
Level 6
Partner    VIP    Accredited Certified

Two-step catalog recovery described in this TN:

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

 
For UNIX and Linux:
  • 1. Run the catalog recovery wizard and select the option for Partial catalog recovery
    2. When the recovery operation completes edit the bp.conf file and add the FORCE_RESTORE_MEDIA_SERVER setting.
    3. Run the command bprecover -r -nbdb to recover only the NBDB


This 'two stage' approach is required on UNIX and Linux because the catalog recovery process restores the bp.conf before restoring NBDB and thus overwrites any FORCE_RESTORE_MEDIA_SERVER setting configured before the catalog recovery is started.

 

jim_dalton
Level 6

js- this is a catalog recovery -say at Disaster Recovery- via the 'Recover the catalogs' button or cmdline equivalent.So there is no option to exclude bp.conf, though it might be nice if there was.

I do feel it ought to be documented, maybe thats just me expecting too much.

As for the other solutions, I'm sure they are good, but in the end I chose to add the

FORCE_RESTORE_MEDIA_SERVER = <media server doing the catalog backup> <master server>

into my source (master) bp.conf and the recovery went through end to end, no hiccups , no issues , clean and perfect. For me, this works.

Thanks all for your suggestions,Jim.

Do I award myself points for my solution?

Marianne
Level 6
Partner    VIP    Accredited Certified

Your workaround is good for the DR testing, but may cause problems in the long run if you leave the FORCE_RESTORE entry on your production master.

The 2-step restore is indeed documented in the TN that I have posted above.

jim_dalton
Level 6

Hi MvdB The only issue I can see is the restores (which we do once in a while) will be misdirected, which we can cancel and correct, my Operations are aware of it. Its a balance and if we have a disaster then I want recovery to be as smooth as possible. For me I'm happy with the trade-off, unless you can foresee other problems (in the long run)? 

TIA,Jim