About BMR server restore

[Lotfi_BOUCHERIT]

Hello,

I have couple of policies with ALL_LOCAL_DRIVES as backup content and the backup clients are servers containing more than one disk partition (SYSTEM C: + Data partition D:).

When I want to restore the server, it only restores C: drive and it does not restore the second partition.

In the PREPARE FOR RESTORE step, here what i select:

I would like to know now, if this is a normal behaviour of Netbackup or i have to do something else to recover all the partitions besides the System drive??

thanks in advance for your help.

[Yasuhisa_Ishika]

I suppose you are recovering the system onto alternate machine as "Configuration" is not "current". PleSe check in this configuration if disk partion and volumes are well configured and mapped.

BTW, please tell us the version of NetBackup running on master server, BMR boot server, and client.

[Jaime_Vazquez]

BMR will only restore those volumes/partitions that are noted in the "Volumes" section of the restore configuration, without regard to the file selection list used at backup time. The only deviation of this is if the "Restore system disks/volumes only" is used at Prepare To Restore time. In making a copy of a configuration, you are able to map out only those partitions that you feel need to be restored as part of the recovery action. In cases where a client has SAN attached disks, most customer will just restore the local disks and let the recovered client automatically reattach to the SAN drives. The logic for this is simple:  If the problem is with the local OS disk recovery but the data in the SAN drive is OK, there is no need to do a full recovery of working valid drives.  If the error is with the SAN drives but the OS is OK, there is no need for a BMR recovery. Normal NBU file restore actions can be used from either the client or the Master.

If there is a problem with the disk layouts that is encountered at actual restore time, then BMR will kick out to the Auto-DDR process. Note that this will only happen if the system volume/partition could be mapped to a visible drive. If the disk sizes that are "seen" at restore time cannot fully allocate the system partition, the restore will just fail out. BMR allocates partitions based on the created size (as seen in the restore configuration - the sizes can be modified and manipulated), not the used space size. Anyway, when this process is invoked, the system partitions will have been pre-allocated but the data partitions are not. If you just hit the "OK" button at that time, you will only get the system partitions restored.  In order to get the full set of known partition/drive letters restored, you will have to manually map them.  One side effect of the Auto-DDR process is that all secondary disks are automatically restricted from use by BMR. It's like they never existed.  This is a safety mechanism so that BMR does not accidentally wipe out valid disks. Back in very early 6.5 days, at a customer POC demonstration, BMR accidentally wiped out 9 SAN attached disks because of the faulty logic. Anyway, to get access to these secondary disks, look in the section marked "Empty Disks".  You need to choose each disk and exercise the "remove restriction" flag from each. Then you will be able to select the other partitions (as noted in the "Original layout" panel.) and map them accordingly.  It is important to note that part of the process allows you to modify the sizes and locations of the other partitions as well. The size of the system partition can also be changed but it cannot be moved. The updated panel "Layout to be used for restore" will be the active disk layout for the restore of BMR. Once you re satisfied with this, you can then hit the OK button.

You can actually force BMR into this same scenario ahead of the restore, by issuing the following command (in the normal NBU bin folder) on the Master Server:

bmrovradm -enable "Force DDR"

The use of bmrovradm -list will show it active. The command bmrovradm -delete "Force DDR" will remove it. Until removed it will stay active. There are several additional sub-options to the command to restrict its use to specific clients and their specific configurations.  Use bmroveradm -? to get full syntax.  This command is only applicable to Windows client restores.

So, bottom line, look at the restore configuration and see exactly which partitions it shows are to be active to the recovery. I tend to select the configuration and choose the 'change' button to see it.  I also like using the 'disk view' setting as well.

I hope this can assist you in finding out why the D drive was not recovered.

[Lotfi_BOUCHERIT]

hello,

Thank you so much for your answers. First of all, i would like to check with you the steps that i am following in the BMR restore process (if you permit):

• Creating the Shared Ressource Tree (which I do it once, for every hardware Architecture x64 or x86 processors for ex.) if this is not done before.
• Discover the hardware configuration of the server that will be used to restore the backed up server.
• Change the configuration according to the discovered configuration (initializing Devices and Drives, Network Interfaces, Volumes)
• PREPARE_TO_RESTORE as the picture already posted in my first message (i understood from this article "after translation" : http://www.symantec.com/business/support/index?page=content&pmv=print&impressions=&viewlocale=zh_CN&... that this step helps fetching drives for the discovered configuration and inserting them in the Shared Ressource Tree)
• Creating the BMR CD.
• Restoring the client.

Yesterday after the answer of Sir. Yasuhisa Ishikawa, i restarted the restore operation but this time, i didn't initialize in the Change process of the configuration (because i am restoring on an alternate configuration) so the two volumes (C and D drives) still figured in the Volumes node (in the Change configuration window). But when booted with the BMR CD, it hung in the Establishing restore environment and the same Change Configuration window popped up and i had to initialize the volumes. Once i did this, the D drive disappeared from that node.

And when i clicked ok to continue the restore, it is not restoring the D drive. I precise that all files of the original server in the D drive,do exist in that backup. To be sure of that, i did restore some files to confirm that.

Thanks for your reactions and your help in advance.

Regards

[Jaime_Vazquez]

For SRT puirposes, a 32 bit SRT is required for 32 bit Windows clients.  A 64 bit SRT is required for 64 bit Windows clients. In reality, only 4 SRT entries are sufficient for restoring any Windows client. A network based 32 bit and 64 bit SRT, as well as ISO images created from them. An additional trick/tip: you can pre-install all of the needed drivers sets for all clients in your production farm at any time ahead of any BMR recovery. Simply perform a Prepare To Restore (PTR) for sufficient clients to have all of the drivers installed in the network SRT. Once a  driver set is added into an SRT, it stays resident unless manually removed.  It can be updated if a later version of the same driver set is used in the PTR.

When you initialize from a discovered configuration you must do a 'Remove restriction' of all of the discovered disks. Nothing is pre-allocated so all desired recovery partitions must be allocated ahead of time.

Technically speaking, a Prepare To Restore is not required for recovery of Windows clients unless it involves some of the available options  (like 'restore system disks/volumes only' and 'use external procedures'), if it involves network boot or the SRT needs new device drivers installed in it. Also, if a device driver set is marked as "Windows native driver" , then BMR will not harvest a driver set as the WIndows installlation itself already has one resident and a compatible driver will already exist in the SRT.

One last thing, just make tings completely clear.  You stated "the D drive disappeared from that node". If the restoring client is a node of a cluster and the drive letter in question is seen as a shared cluster resource, BMR will NOT restore it as part of the recovery.  BMR takes the very conservative approach that it will only recover those resources that are local to the client as it cannot determine at restore time if the resource is potentialy in use by another node. I covered this in this TECH article:

BMR and cluster node restores
http://www.symantec.com/docs/HOWTO84852

Lastly, all of the activity that BMR performs on any client (Windows/Unix/Linux) during any BMR recovery is logged on the Master Server. The unified logging ID for 'bmrrst' is 131 but it is preset in the Windows SRT at DebugLevel=4. It does not react to any vxlog commands for that reason. For Unix/Linux clients, Unified logging is not even used.  The file path of the data is:

$INST_PATH\NetBackup\logs\bmrrst\$CLIENT_NAME\MMDDYY.log (Windows Master)
/usr/openv/netbackup/logs/bmrrst/$CLIENT_NAME/log.MMDDYY  (Unix/Linux Master)

If the file is not present BMR will create it. If present BMR will append to it.  For Unix/Linux clients, the log will hold information equivalent to TAR logging within the file itself. As such, the files can be rather large, especially if multiple restores are performed on the same client multiple times in a day.

Peruse the restore log file entry for your client to see if the D:\ drive was marked as an entry for restore actions. If you want, you can add a comment and attach the debug log for review.

BTW, as your client did get as far as it did, all neeed device drivers are already part of the SRT. A PTR is not needed for your ISO image boot.

[Lotfi_BOUCHERIT]

Hello and Good morning,

I found that log file in the BMRRST but i can't get any useful information from it.. I find some logs with failures and related to disk and volumes.

Would you mind check the joint file please?

Thanks in advance, Regards

[Jaime_Vazquez · Accepted solution]

Based on the restore log, BMR on the client only could find/see one disk on the system. The restore configuration has two disk entries in it.  I presume harddisk0 is for the C:\ and harddisk1 is for the D:\. The log shows:

4 DEBUG mergeconfigs.cpp:LocalMatchDisks() SCSI match, disk id=12135 to 5
4 DEBUG mergeconfigs.cpp:LocalMatchDisks() Size match (LDM BPC), disk id=12134 to 4
2 DEBUG mergeconfigs.cpp:LocalMatchDisks() Could not find a match for disk, id=12133
3 DEBUG mergeconfigs.cpp:MatchDisks() Could not match disks, rc=1007

disk id 12134 and 12135 are the harddisk0 and the CD ROM drives. Disk id 12133 has no viable match on the hardware.It is either totally missing or of a size smaller that what the restore configuration is holding. For this reason it dropped into the runtime DDR process wizard.

2 DEBUG ddr_detect.cpp:IsDissimilarDiskRestore() Errors while matching disks, assuming DDR, rc=1001
4 DEBUG CWinPeRestoreStrategy.cpp:step() Current step=Dissimilar Disk Mapping

This wizard will allow you to make changes to the partition allocation map for recovery purposes. If you just hit "OK", only the system partition will be recovered.  In the panel, choose the selection "empty disks". In that panel choose the 'disk view' selection. It is more intuitive to use.  If there are no entries shown, then there was no other disk seen on the hardware. This could be a hardware problem or a logical drive configuration issue on a RAID adapter. BMR does not perform RAID configuration.  That is a user action at boot time.

If a disk is visible in the panel, right click on the drive and choose 'remove restriction'. If the 'empty disks' option is not visible, there were no other disks to be seen. Anyway, from there go to the "Volumes -> Windows disk management -> Disks" selection.On the right side, choose 'disk view'.

The panel will have two sections. The top section is "Original volume layout". The bottom is 'New volume layout'. The 'Original' layout came from the restore configuration being used.  The 'New' is what BMR will create for the recovery.  At this time, no disk writes or allocations have been performed. The 'Original' should be showing two disk drives, with their captured sizes. It will also show all of the original partitions, their drive letters, some major properties (if present) and their sizes. Right click on a partition and choose to 'map' the partition. The mapping wizard will then fire off and you can use it to do the partition mapping.  This is identical to the activity if run on the Master Server when making changes to a configuration. From the disks available section, choose a drive and do an 'Add'. The panel has an entry where the partition size is preloaded. The panel also shows 'Available space' on the drive. You can change the allocation size to any value, as long as the size is large enough to hold the recovered backup image.  BMR notes this in there as well. If there is sufficient space available on the hard disk0 entry, you can map to it, i.e. map both partitions to the single disk.  

You can also resize the C:\ drive as well during this process. If you choose it you will not get a 'map' option, but an option to change the size. It can be shrunk  to make free space on the disk, but only to a size large enough to hold the backup image. It can even be enlarged to a bigger size if the disk has room.It cannot be unmapped and moved to another disk drive. If you do this first and free up enough space on the first disk, you can then map the second partition to it. When mapping is completed, use the "OK' button and BMR will continue on using the new layout for the disks. It will only manipulate those disk and partitions that were mapped. It will only recover those drive letters in the layout when doing the 'bprestore'.The restore selection is also noted in the log:

4 DEBUG CWindowsRestoreStrategy.cpp:setFileSystemsToRestore() Adding C: to restore list.

BTW, the log also shows a restore time failure:

 DEBUG nbutils.cpp:NBURestore() Restore command failed! Tried (bprestore -w   -L C:\BMR\nbulog.txt  -T   -f "X:\listfile.txt" )--rc(150).
1 DEBUG nbutils.cpp:NBURestore() content of listFile ( 27 C:\WINDOWS\system32\config\ 1404386607 1404807258
 )

That is a status code 150 return code when attempting the restore of "C:\WINDOWS\system32\config\". You need to look at the Admin console for this.

[Lotfi_BOUCHERIT]

hello,

first of all, i would like to thank you for your help... i tried almost of the steps you talked about in your previous messages, and it still does not work. i tried to map the drives one by one, but later when started to restore i got error --rc(25)

what i did, is restore the C drive and then restore the D drive as flat files and it did work, but the duration of the restore was enormous, but this remains acceptable with the errors and difficulties of the bmr restore

thanks and regards

[Jaime_Vazquez]

The "rc=25" error is a network issue. It has nothing to do with the disk partitioning. The client cannot connect to the server it "thinks" is the Master or the Media Server when issuing NBU commands.