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.
