Forum Discussion

manmountain's avatar
manmountain
Level 5
11 years ago

[Error] V-126-3 'bmrprep' could not complete the requested operation

Hi, I am attempting to do a BMR on a client. I am getting this error below. I have attached a log of the process bmrprep in debug mode. 

[Error] V-126-3 'bmrprep' could not complete the requested operation.

The Shared Resoutrce Tree could not be shared by the Boot Server hosting it. Please verify that the required configuration in the Boot Server is correct. The nfs daemons and configuration files need to be properly working for this operation to work. 

Just wondering would anyone have any ideas on what is causing this error. From looking through the logs it is not to clear on what is causing this problem. 

Thanks!

 

7.5
Backup and Recovery
NetBackup
Restore
Solaris
  • katlamudi's avatar
    katlamudi
    11 years ago

    I could see multiple problems in your case:

    1) SRT allocation failing due to invalid network services configuration on Bootserver.

    For network services configuration on boot server, please refer later Netbackup BMR Administrator guide section"Solaris Network configuration" of Appendix A.

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

    2) Even after you configure your network settings properly, you may see failures during recovery. I can see ZFS is configured on your solaris server and BMR support for solaris servers with ZFS is added from Netbackup 7.5.0.x. It seems your client with which backup was taken is still at 7.0. Unless you have NB7.5.0.x or higher version of client on Solaris client, Netbackup will not be able to backup complete bare metal restore informaion of ZFS filesystems for the client.

     In that case, if client OS volumes are not on ZFS, you need to restrict the ZFS based disks in BMR configuration and use it BMR Prep with "Restore System Disk/Volumes only" option.  

    OR

    Upgrade the client's NB software to 7.5.0.x and take a fresh backup. Using that you can recover your solaris client without issues.

     

    thanks,

    katlamudi

  • manmountain's avatar
    manmountain
    Level 5
    11 years ago

    I can see that when the process attempts to get the server info it comes back with the incorrect name. 

    [bmrprep.cpp:GetServerInfo()] Entering
    [bmrprep.cpp:GetServerInfo()] Exiting, <Incorrect Name>

     

    Is it possible to change this?

  • katlamudi's avatar
    katlamudi
    Level 4
    11 years ago

    1) "[bmrprep.cpp:GetServerInfo()] " function returns the Master server name with which client backup has been taken. It seems it is not a problem here. Confirm if this is the rigth master server or not?

    2) As allocateSRT step failed, please check "bmrbd" logs in "Bootserver" on which the SRT is present.

    BMRBD Log id is 119.

     

    thanks,

    katlamudi

     

     

     

     

  • manmountain's avatar
    manmountain
    Level 5
    11 years ago

    Hi katlamudi,

    1) It is coming back with the incorrect master server name.

    2) I have attached bmrbd log. just see 'client did not send VxSS magic' in the logs.

  • katlamudi's avatar
    katlamudi
    Level 4
    11 years ago

    Hi,

    1) Regarding the master server name:

    The master server name returning indicates the master server using which the client was backed-up. You might be doing bmrprep on old Point In Time backup image OR  a backup image which was imported.

    In that case you may need to change the master server entry by create the copy of configuration and edit the "host" section to reflect new master server name.

    Please edit bmr configuration as mentioned above.

     

    2) Regarding the above shared boot server log:

    The log(bmrbd.txt) you shared above seems incomplete and its date and time are not matching with the bmrprep log you shared in first post.

    While generating high verbose log for Bootserver acitvity, make sure that high  verbose level(6) is set for "119"(bmrbd) and "128"(bmrcommon) log ids.

    Then repeat the bmrprep and share

    (i) BMRPREP log from master server and

    (ii) BMRD/BMRBD and BMRCOMMON logs from boot server..

     

    thanks,

    Katlamudi 

     

  • manmountain's avatar
    manmountain
    Level 5
    11 years ago

    It appears that the disks are labelled as EFI. I have learned that this is not supported. However it seems that they the primary disk is SMI so I wonder can I restore this.

     

    25/04/2014 12:55:02.249 [bmrprep.cpp:ConfigUnix()] Disk Data File:
    ../../devices/pci@0,0/pci10de,375@f/pci108e,286@0/disk@0,0:q 586758574080 SMI
    ../../devices/pci@0,0/pci10de,375@f/pci108e,286@0/disk@1,0:q 146685296128 EFI
    ../../devices/pci@0,0/pci10de,375@f/pci108e,286@0/disk@2,0:q 146685296128 EFI
    ../../devices/pci@0,0/pci10de,375@f/pci108e,286@0/disk@3,0:q 146685296128 EFI

  • katlamudi's avatar
    katlamudi
    Level 4
    11 years ago

    I could see multiple problems in your case:

    1) SRT allocation failing due to invalid network services configuration on Bootserver.

    For network services configuration on boot server, please refer later Netbackup BMR Administrator guide section"Solaris Network configuration" of Appendix A.

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

    2) Even after you configure your network settings properly, you may see failures during recovery. I can see ZFS is configured on your solaris server and BMR support for solaris servers with ZFS is added from Netbackup 7.5.0.x. It seems your client with which backup was taken is still at 7.0. Unless you have NB7.5.0.x or higher version of client on Solaris client, Netbackup will not be able to backup complete bare metal restore informaion of ZFS filesystems for the client.

     In that case, if client OS volumes are not on ZFS, you need to restrict the ZFS based disks in BMR configuration and use it BMR Prep with "Restore System Disk/Volumes only" option.  

    OR

    Upgrade the client's NB software to 7.5.0.x and take a fresh backup. Using that you can recover your solaris client without issues.

     

    thanks,

    katlamudi