Forum Discussion

asherh1's avatar
asherh1
Level 3
10 years ago

Netbackup support for UEFI based systems

Restore an entire UEFI support system with Netbackup can be done only to the original machine .

Symantec System Recovery 2013 support hardware independ recovery of UEFI based systems.

Is there any solution on roadmap for hardware independ recovery of  UEFI based systems with Netbackup ?

Thanks,

Asher

  • The use of different disk models can have a side effect.  Even if it is stated to be the same size, under the covers they can be incrementally different, This is because the geometry of the disk can differ. By that I mean things such as bytes per sector, sectors per track, bytes per cylinder. BMR uses this disk geometry information when allocating and formatting individual partitions. Windows partitioning is performed on a cylinder boundary and the amount of space requested may be rounded up to the next cylinder boundary because of it, If I remember correctly, the Windows API used calls for the number of bytes to be allocated. It then calculates the number of cylinders needed on the specific disk to satisfy the partitioning request. For a disk where there was no free space available, partitioning can fail with an insufficient space error. This is especially true if multiple partitions are being allocated on the same disk and cylinder rounding up is occurring. BMR has no control over this as it is part of the Windows API. This in turn can change internal disk pointers to the start and end of a partition being allocated.

    That being said, if restoring to a uEFI system and there is a need to replace a disk, it is optimal to use the exact same disk model number as the failed disk. If not possible, try using a disk from the same disk family that has the same geometry but has more total cylinders (larger capacity disk). All allocations start with cylinder zero and are offsets from there. The offsets should stay the same.

     

    Now, as for the teaming stuff, understand that BMR does not make use of any teaming/bonding software for any recovery. BMR has no mechanism to install such software into an SRT or to configure the interfaces in that manner.  It makes use of the physical interfaces only for the actual recovery.. .Post restore, upon reboot, the teaming software itself will fail if the NIC adapters on the recovered server do not exactly match the adapters that were on the backed up server. Teaming/bonding software requires  local configuration files to determine which NIC adapters to team/bond and in what manner. The configuration is tied to the MAC address of the adapters. Restores back to the exact same server that created the backup image (and the same NIC adapters) and making use of the "current" configuration will allow the restored teaming software to work properly. When using the "current" configuration at restore for Windows clients, BMR will assume it is not a DSR recovery and will skip DSR activity. For all other restores it will assume a DSR restore and perform all DSR work. If restoring back to the exact same server but using a copied configuration where the network interface information (MAC address, IP)  has not been modified, the teaming setup can be restored properly by using the following command on the Master Server ahead of the restore attempt:

    bmrovradm -enable "Disable NIC DSR"

    This will cause the post-restore process to skip NIC DSR actions and leave all settings in place in the restored Registry. The command needs to be run and set ahead of the restore attempt. It is not affected by a Prepare To Restore. You can view/delete the setting by running:

    bmrovradm -list     (lists out the status of override settings on the Master)
    bmrovradm -delete "Disable NIC DSR" (removes the setting from the running Master)

    The "bmrcleanup.exe" process should always be invoked on first reboot after a successful recovery. It is "hooked" into the registry to run on reboot. The registry key is deleted as part of the cleanup process. If client networking is not operational, it will complete with a RC=200 error panel.  This is not a failure of the recovery.  The last step performed by the cleanup process is a message to the Master to change the status of the client restore task in the "Tasks" section of the Admin console. It does not affect the recovered client. Please see this article for details:

    During Bare Metal Restore (BMR) Final Cleanup, the error message "Unable to update client state on the Netbackup server, error =200" is displayed.
    http://www.symantec.com/docs/TECH73586
     

     

     

  • This TN for v7.5 implies not:

    https://support.symantec.com/en_US/article.TECH190513.html

    ...and this TN links to a TN describing manual system recovery using an 'overlay' method:

    https://support.symantec.com/en_US/article.TECH56473.html

    N.B: the leading TN above is for NetBackup v7.5.

    .

    In this next forum post a Symantec employee hints/suggests thatmaybe UEFI support for NetBackup BMR is coming in a future release:

    https://www-secure.symantec.com/connect/forums/restores-ibm-running-uefi-and-hp-servers-running-bios

    .

    Page 21 of the NetBackup v7.6.0.2 Release Notes details how BMR Fast Restore, and an additioal step re BIOS boot, can be used to restore/recover an EFI based system:

    https://support.symantec.com/en_US/article.DOC6840.html

  • UEFI restore is supported for Netbackup BMR , but only to original server . Restore is not supported even if we replace the  system disk .

    We try the step described on page 21 of the Netbackup 7.6.0.2 Release Notes , without success.

  • Someone on this post appears to have gotten it to work:

    https://www-secure.symantec.com/connect/forums/uefi-bmr-restore-netbackup-76

     

  • I saw the post , it's the same situation as I decribe.

    From the end of the post:

    "Well I am shocked with this BMR restoration behavior because this killed the meaning of BMR. We can restore it on Dissimilar hardware :( if my hardware goes down my BMR backup is use less for me accept file level restoration. "

     

     

  • Let's hope for a supported solution/configuration in an upcoming release.  :)

  • I had the same issue at a customer.

    It's true that you can only restore it to the same Hardware! We used different disks (same Size, but different part-number and the new ones were 12Gbps. The old had 6Gbps) We had a lot of problems like: NIC teaming didn't work, formatting the disks failed.

    We got an ISO File and SRT from the support which rebooted the system after Restore. The BMR cleaning job started automatically. Then we had the Problem with the teaming.

    We made a SRT and used an ISO where we manually added the drivers. In this case the BMR cleaning job didn't start automatically.

    Hope there will be a solution shortly!

     

  • The use of different disk models can have a side effect.  Even if it is stated to be the same size, under the covers they can be incrementally different, This is because the geometry of the disk can differ. By that I mean things such as bytes per sector, sectors per track, bytes per cylinder. BMR uses this disk geometry information when allocating and formatting individual partitions. Windows partitioning is performed on a cylinder boundary and the amount of space requested may be rounded up to the next cylinder boundary because of it, If I remember correctly, the Windows API used calls for the number of bytes to be allocated. It then calculates the number of cylinders needed on the specific disk to satisfy the partitioning request. For a disk where there was no free space available, partitioning can fail with an insufficient space error. This is especially true if multiple partitions are being allocated on the same disk and cylinder rounding up is occurring. BMR has no control over this as it is part of the Windows API. This in turn can change internal disk pointers to the start and end of a partition being allocated.

    That being said, if restoring to a uEFI system and there is a need to replace a disk, it is optimal to use the exact same disk model number as the failed disk. If not possible, try using a disk from the same disk family that has the same geometry but has more total cylinders (larger capacity disk). All allocations start with cylinder zero and are offsets from there. The offsets should stay the same.

     

    Now, as for the teaming stuff, understand that BMR does not make use of any teaming/bonding software for any recovery. BMR has no mechanism to install such software into an SRT or to configure the interfaces in that manner.  It makes use of the physical interfaces only for the actual recovery.. .Post restore, upon reboot, the teaming software itself will fail if the NIC adapters on the recovered server do not exactly match the adapters that were on the backed up server. Teaming/bonding software requires  local configuration files to determine which NIC adapters to team/bond and in what manner. The configuration is tied to the MAC address of the adapters. Restores back to the exact same server that created the backup image (and the same NIC adapters) and making use of the "current" configuration will allow the restored teaming software to work properly. When using the "current" configuration at restore for Windows clients, BMR will assume it is not a DSR recovery and will skip DSR activity. For all other restores it will assume a DSR restore and perform all DSR work. If restoring back to the exact same server but using a copied configuration where the network interface information (MAC address, IP)  has not been modified, the teaming setup can be restored properly by using the following command on the Master Server ahead of the restore attempt:

    bmrovradm -enable "Disable NIC DSR"

    This will cause the post-restore process to skip NIC DSR actions and leave all settings in place in the restored Registry. The command needs to be run and set ahead of the restore attempt. It is not affected by a Prepare To Restore. You can view/delete the setting by running:

    bmrovradm -list     (lists out the status of override settings on the Master)
    bmrovradm -delete "Disable NIC DSR" (removes the setting from the running Master)

    The "bmrcleanup.exe" process should always be invoked on first reboot after a successful recovery. It is "hooked" into the registry to run on reboot. The registry key is deleted as part of the cleanup process. If client networking is not operational, it will complete with a RC=200 error panel.  This is not a failure of the recovery.  The last step performed by the cleanup process is a message to the Master to change the status of the client restore task in the "Tasks" section of the Admin console. It does not affect the recovered client. Please see this article for details:

    During Bare Metal Restore (BMR) Final Cleanup, the error message "Unable to update client state on the Netbackup server, error =200" is displayed.
    http://www.symantec.com/docs/TECH73586