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

Monitoring job progress and finalizing a recovery with Plug-in Live Client for Linux

From the NetVault Backup Server, you can monitor the progress of any job through the Job Status page. While it is not necessary to monitor a job’s progress, Quest recommends that you monitor progress when performing a recovery of a NetVault Bare Metal Recovery Client. After the recovery of a Linux NetVault Bare Metal Recovery Client has completed, you must perform a last task to bring it back online. By monitoring the recovery job, you are alerted to the completion of a job and this final task can be performed.


	NOTE: This topic offers an example of the use of the Job Status page of the NetVault Backup WebUI for monitoring the progress of a Linux DR recovery operation to finalize the job. The tools made available in this dialog box are not exclusive to the Plug-in Live Client for Linux and complete information about their use can be found in the Quest NetVault Backup Administrator’s Guide.

With the recovery job running, click Monitor Job in the Navigation pane.

In the list of jobs displayed, locate the in-progress Linux DR recovery job.


	IMPORTANT: If you must stop the job, you can also access the Abort command the same way. If you use this command to stop a recovery job, NetVault Backup stops the transfer of data. However, the System Installation for Linux application currently running on the Linux NetVault Bare Metal Recovery Client stalls and its commands, while still accessible are not usable. A full reboot of the Linux NetVault Bare Metal Recovery Client must be performed with the CD inserted in the drive to reactivate the application for use.

Various information pertaining to the selected job is displayed, including the plug-in in use and data-transfer-rate values. The Run Status field displays the status of the job, for example, Waiting for Media or Reading from Media. As the recovery completes, data transfer values stop and this field is updated to Restore Complete.

To complete the recovery process, locally access the Linux NetVault Bare Metal Recovery Client machine, and reboot it by using the Reboot the System command in the System Installation for Linux application — type exit at the maintenance shell prompt, or manually shut down the system.

The Linux NetVault Bare Metal Recovery Client boots and its file system should be recovered to the point when the DR image was taken.

"Superblock last…" messages appear during fsck process

“Superblock last…” messages appear during fsck process

You might encounter an issue with a restore that causes either fsck errors related to clock inconsistencies or forced checks on systems that do not use Universal Time Coordinated (UTC). These errors appear as “Superblock last mount time is in the future” messages the first time that the system is restarted after the restore. You can ignore this issue, or you can work around it by using the following steps:

Use the Storix media to boot the target client.

Open a maintenance shell in Storix, and run the following command.

hwclock --hctosys --localtime

Perform the restore.

Completing post-restore requirements for use with Plug-in Live Client for Linux

After a restore process completes on a target Linux Client, the following points apply to that machine:

•

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.