Full Linux and windows restore without BMR option

If you can use BMR for this, it is all the better. But, if you are not set up for a BMR restore and need to do a full system recovery, then the TECH article for Windows will do you well.  It has been used by many and it is a working solution.  The actions of Windows kernels during a overwrite action differ significantly from a Linux/Unix restore with overwrite. Windows recognizes i a file has already been loaded into to memory an will no0t disturb the running system,  It will do the restore and flag it.  In the details of the restore job you will see messages stating to the effect that the file will only be active upon a reboot.

For Unix/Linux, this is definitely not the case. An overwrite of a critical system file, such as "libc" will crash the system with a kernel panic. It is not a good thing. Recovery of such clients without use of BMR requires a few things to be done as part of the process.  This will make a nice TECH article for me to write. Anyway, here are the needed steps:

1. All system files need to be restored to an alternate disk. As such you will need to have at least two disks for this to work. One disk with be the working OS disk with the needed NBU client software installed. It will need to have the credentials of the restoring client, as seen by the NBU Master and any Media Server in use.The second disk will be the target of the restore actions.

2. The source client system can be as minimal as you care to have it. It needs a working OS at the same release as the backup client image. Kernel versions do not have to exactly match, but it helps. The host name and IP address information needs to be properly resolved on the NBU servers.  If the source machine of the backup needs to remain on the network during the recovery phase, you will need to "spoof" the Master Server by assigning an unused IP address to the host name for the duration of the restore. Add a temporary entry in the /etc/hosts file that has the needed host name to IP address resolution. Clean this up after recovery completes.

3. For the sake of an example, let us assume that the two disks are device paths /dev/sda and /dev/sdb.  The /dev/sda is the running recovery server, the /dev/sdb is the image target server. 

4. On the target /dev/sdb disk, allocate all of the needed partitions of the backup image. The sizes of the partitions need to be as large or larger than the amount of data that will be recovered into them. They do not have to match what the original server partition allocations were. 

5. Create the appropriate file system on each partition. 

6. Create a mount point directory on the source server. It can have any name you desire. Create sub-directories to match the 

target image. Here is example information:

Assume the following file systems noted in the backup image:

  /boot
  /  (the root file system)
  /usr
  /export
Create these mount points directories.
 
  mkdir /RECOVER
  mkdir /RECOVER/boot
  mkdir /RECOVER/export
    

7. Mount each file system allocation from the /dev/sdb disk to these mount points:

mount -o rw -t ext3 /dev/sdb1 /RECOVER/boot
mount -o rw -t ext3 /dev/sdb3 /RECOVER
mount -o rw -t ext3 /dev/sdb4 /RECOVER/usr
mount -o rw -t ext3 /dev/sdb5 /RECOVER/export

/dev/sdb2 will be the swap for the recovered client.

8. Create a rename file to be used for the restores of the file systems.  This will redirect the files from their normal  /dev/sda location to the corresponding /dev/sdb location. As an example:

change /usr to /RECOVER/usr
 

9. Initiate the restore to the client using the "bprestore" command. Use the "-r" option flag to designate the rename file. You can restore file systems individually from the command line or use a list file to get all included in one action.  The "-f " flag is used for that. I also recommend the use of the "-w" flag.

See the NBU Commands reference for more information on the named options above.

10.  Once all of the files have been restored, you will need to install a boot image/grub loader into the recovery disk to make it bootable. Make sure that the mount table is correct on the recovery disk.

11. Shutdown the recovered client and remove the original source (/dev/sda) disk.

12. Reboot using the newly recovered disk as the boot disk.

If all went well, it should come up normally. Log in an verify settings.  Make changes as desired.