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 ...
7.6
Backing Up
Backup and Recovery
NetBackup
Recovering
Restore
Windows Server (2003-2008)
  • Jaime_Vazquez's avatar
    Jaime_Vazquez
    10 years ago

    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
     

     

     

Jaime_Vazquez's avatar
Jaime_Vazquez
Level 6
10 years ago

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