NetVault Bare Metal Recovery 11.4 - User Guide for Plug-ins

The “hosts” file for the Target is modified: A restore modifies the target NetVault Bare Metal Recovery Client machine’s entry in its “…/etc/hosts” file; for example, after recovery, the host name does not appear along with the IP address and the alias for this client in the “…/etc/hosts” file. The machine is still accessible through its IP address, but for it to be accessible through its host name, this file must be edited to incorporate the appropriate host name information. For information about this “hosts” file and how it should be edited to include the proper host name for the target Linux machine, see the relevant Linux documentation.

•

Perform a restore of the modified files backup (if applicable): With the recovery completed, you can now restore the files backed up in the Plug-in for FileSystem backup described in Recovering a DR image for use with Plug-in Live Client for Linux. This process restores these files to their state before the DR recovery.

•

Change to boot loader application: If running a version of the Linux boot loader utility other than GRUB, after a DR image is recovered on a target Linux Client, the boot loader utility is replaced with the GRUB version of this application.

•

GRUB entries: Storix never assumes that you are reinstalling onto the same physical hardware or restoring to the same storage configuration. Therefore, it is never guaranteed that the previous GRUB entries are valid. The only GRUB entry guaranteed to be valid after restore is the entry created by Storix.

•

Volume labels and Volume UUIDs: For systems that use universal unique identifiers (UUIDs) for booting or mounting, review and edit the “/boot/grub/grub.conf” and “/etc/fstab” with the correct device UUID. For more information, see Updating the UUID information manually.

•

Change in the start-end sector location for a DR restore: After a recovery of a DR image, the start-end sector for a restored partition may be different from its original backed-up location. The partition size remains the same size, but no unallocated space is created after the Master Boot Record. Therefore, some boot loaders, for example, GRUB, are not usable, because they require this additional, unallocated space. This requirement is because the Linux Loader (LILO) version of the boot loader utility that is automatically established after a recovery, as explained previously, does not require this unallocated space.

•

Change to swap partition: During a recovery, the NetVault Bare Metal Recovery for Linux module implicitly modifies the “/etc/fstab” file entry for the swap partition.

Example:

For example, before the restore, “fstab” contains the following entry for the swap device:

LABEL=SWAP-sda2 swap swap defaults 0 0

After the restore, the original swap entry is commented out and a new entry is added:

# Updated by Storix System Installation

#LABEL=SWAP-sda2 swap swap defaults 0 0

/dev/sda2 swap swap defaults 0 0

The swap partition is enabled automatically, but the label for the swap partition is removed.

•

File-system checking is enabled: A restore modifies the “Maximum mount count” and “Check interval” parameters, which enable file-system checking. For systems that should not have these parameters enabled based on the number of mounts or a specific period, use the following commands to disable the options manually:

# tune2fs -c -1 <deviceName>

# tune2fs -i 0 <deviceName>

Updating the UUID information manually

The UUID of each file system is re-created when you use the Plug-in Live Client for Linux to restore data. If the UUID is used in the “/boot/grub/grub.conf” and “/etc/fstab” files and they are restored from a previous backup with the Plug-in for FileSystem, the system fails to boot because the UUID values do not match the values on the actual file systems. To work around this issue, manually update the files.

The following procedure shows commands that use examples such as “dev” and “sda.” When running these commands in your environment, replace the applicable information with the correct information for your environment.

Use the Plug-in for FileSystem and a previous backup to restore the “/boot/grub/grub.conf” and “/etc/fstab” files to the working directory.

To identify and note the name of the device file and its mount point, run the following command:

# mount | grep ^/dev

/dev/sda3 on / type ext4 (rw)

/dev/sda1 on /boot type ext4 (rw)

To identify and note the swap device information, run the following command:

# swapon -s

Filename Type Size Used Priority

/dev/sda2 partition 2097144 0 -1

To export the UUID for the device partition, including the swap information, and save it to a file, run the following command.

Specify each device name, such as “sda1”, “sda2”, and “sda3” after the “in” statement on the command line. A file with the name @device_partition_name@ for each device partition that contains an associated UUID is created in the working directory.

# export LANG=C; export LC_ALL=C

# for dev in sda1 sda2 sda3

> do

> ls -l /dev/disk/by-uuid/ | awk "/$dev\$/

{print \$9}" > @$dev@

> done

Verify that the files have been created for the partition and that the UUID is recorded in each file for its respective partition.

Use a text editor to open the “grub.conf” file.

For the entry that contains “root=UUID=x-x-x-x-x”, match the “x-x-x-x-x-x” to the partition name, and then replace the UUID with the partition name.

Example before change:

kernel /vmlinuz-2.6.32-131.0.15.el6.x86_64 ro

root=UUID=dc8ee87c-1ac3-4ece-ab53-f19cd1ebaf7e rd_NO_LUKS …

Example after change:

kernel /vmlinuz-2.6.32-131.0.15.el6.x86_64 ro

root=UUID=@sda3@ rd_NO_LUKS …

Use a text editor to open the “fstab” file.

Using the information noted in Step 3 and Step 4, change the UUID to the device partition name for all mount and swap partitions.

Example before change:

UID=dc8ee87c-1ac3-4ece-ab53-f19cd1ebaf7e

/ ext4 defaults 1 1

UUID=6c285d5c-9669-4791-a214-2ed007a7e454

/boot ext4 defaults 1 2

UUID=84fd7dad-f9a8-4102-9102-fa62c8def671

swap swap defaults 0 0

Example after change:

UUID=@sda3@ / ext4 defaults 1 1

UUID=@sda1@ /boot ext4 defaults 1 2

UUID=@sda2@ swap swap defaults 0 0

To change the device name to its UUID in the “grub.conf” and “fstab” files, run the following command:

# for dev in @*@

> do

> sed -i "s/$dev/$(cat $dev)/g" grub.conf fstab

> done

Use a text editor to open the “grub.conf” and “fstab” files, and verify that the device names were replaced with their corresponding UUIDs.

Make a backup copy of “/boot/grub/grub.conf” and “/etc/fstab”.

# cp -a /boot/grub/grub.conf /boot/grub/grub.conf.org

# cp -a /etc/fstab /etc/fstab.org

Copy the “grub.conf” and “fstab” files from the working directory to the original location, and re-create the symbolic link from “grub.conf” to “menu.lst”.

# cp -a grub.conf /boot/grub/grub.conf

# cp -a fstab /etc/fstab

## cd /boot/grub

# rm menu.lst

# ln -s ./grub.conf menu.lst

Restart the server, and verify that it starts correctly.

If the system fails to boot, use a rescue disk to start the system in rescue mode, copy back the backup files created in Step 13 to the original location, and restart the server. Review the newly created “grub.conf” and “fstab” files again, make any necessary corrections, and repeat Step 13 through Step 15.

NetVault Bare Metal Recovery physical-to-virtual (P2V) recovery

•

Installing SCSI and IDE device drivers on a physical machine

•

Supported physical to virtual configurations

Installing SCSI and IDE device drivers on a physical machine

If you are using the Linux-based Plug-in Offline Client and you are migrating a physical server to a virtual environment in which the Client is Windows-based, install the disk drivers on the OS before you back up the machine. The restored VM does not boot up because the restored image contains SCSI/IDE drivers for the source physical machine. The restored VM does not have the drivers for the target VM’s SCSI/IDE controller. This issue causes a blue screen error and the boot fails, as it cannot find any disks.

The solution is to create the “.inf” file that informs the Windows installer to load the appropriate drivers to the system and make correct registry entries every time Windows boots. Installation of the “.inf” file is required prior backing up the physical machine so that after the restore, the correct driver is loaded and detects the VMware IDE/SCSI controller.

Quest provides the following device driver “.inf” files:

•

“vm_ide_2008.inf”: IDE device driver for Windows Server 2008

•

“vm_lsi_2008.inf”: SCSI device driver for Windows Server 2008/2008 R2


	NOTE: The device driver must be installed on the source (physical) machine, but the type of device driver must match the target (virtual) machine. For example, to migrate a Windows Server 2008 physical machine with a SATA driver to a VM with a SCSI driver, install “vm_lsi_2008.inf” on the physical machine. For all supported configurations, see Supported physical to virtual configurations.