05-22-2014 07:27 AM
All,
I'm have a Redhat 6.4 server and I'm trying to do a Baremetal restore, but it fails on two accounts. Firstly it says that the disk size is dissimilar, yet I'm restoring to the same box, with the same disk and I'm not talking a replacement disk, I'm actually mean the same disk - non of the hardware has changed at all. To get round this I had to do a discovery and create a new restore configuration; the only problem is that I had to shrink one of the file systems, to get it to fit!
Secondly when I start the restore it fails at various points, with handshaking failed with server backup restore manager(201)). The server I'm trying to baremetal recover is itself a media server, though it doesn't back itself up.
Any ideas?
Thanks
David
Solved! Go to Solution.
05-26-2014 10:45 AM
05-22-2014 03:49 PM
Hello,
What version of NetBackup are you running both client and server. Not sure why you would have a different size drive issue. Really we need logs to trouble shoot this. bmrd, bmrprep, bmrrst, bpcd, bundle.dat
For the status 201 issue check HOWTO35075.
It might be best to open a support case as the amount of logs to review and what to look at is kind of large.
05-23-2014 12:11 AM
Hi,
As my experience, BMR was a complicated and a lot step restore. I say this because i have called symantec support to help me with BMR, but they didn't gave me a "expected" support. I think you need to read BMR Guide Document or watch BMR demo video in symantec site. Maybe its not a good but at least it will help you to understand about BMR.
Best regards,
Iqbal
05-26-2014 07:57 AM
As this is RHEL 6.4, I am assuming this is a NBU 7.6 environment.
The disk sizes are reported to BMR at two times in the entire process. First, during 'bmrsavecfg' time when the client configuration is created. That data is as reported to BMR by the running client OS kernel itself. The next time is at restore time, when the SRT OS kernel is reporting the visible disk sizes.,. Under both circumstances, the data is from standard OS calls and checks, not from any special BMR functions. The data can be seen by looking at the BMR restore log on the Master Server. Assuming a Unix/Linux Master, the path will be "/usr/openv/netbackup/logs/bmrrst/$CLIENT_NM/log.MMDDYY". That should indicate the size of the disks it expected and the size of the disks it saw. Using the discovered configuration you were able to get past the portioning stage of the process, which is good.
The status 201 errors, noted in the HOWTO article, are between the Master and the active Media Server. BMR had no play in any of that. That is totally an NBU issue. There is a section in the BMR Administration Guide that discusses how to restore a Media Server.
Iqbal -I am sorry to hear you did not get the kind of support that you should have gotten. You obviously did not work with me or any of the US/UK/Sydney support engineers that I interact with on BMR issues. BMR can be complicated in some respects, but mostly in the setup. The actual restore process itself, once properly setup and initiated, is almost entirely hands free and recovers the client in as fast a manner as possible. The overhead for a BMR recovery is at mot 2-5 minutes of processing the setup on the client system. The rest is the time it takes to do the actual NBU restore, for which BMR is only acting as an NBU client. All BMR restores are client side requested restores.
05-26-2014 09:35 AM
05-26-2014 10:45 AM
05-27-2014 02:55 AM
Hi,
Well if Redhat 6.4 is not supported in 7.5, then I will look to update and see if it fixes the problem.
And post a response.
Thanks
David