10-29-2012 09:05 AM
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
10-29-2012 09:39 AM
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
10-29-2012 09:44 AM
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.
10-29-2012 10:07 AM
Maybe a dumb idea, but can you just drill down and uncheck the bp.conf file from getting restored?
10-29-2012 10:25 AM
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
10-29-2012 01:42 PM
Two-step catalog recovery described in this TN:
http://www.symantec.com/docs/TECH48819
10-30-2012 03:49 AM
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?
10-30-2012 04:13 AM
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.
10-30-2012 06:13 AM
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