지금 지원 담당자와 채팅
지원 담당자와 채팅

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

Introducing NetVault Bare Metal Recovery Plug-ins Deploying NetVault Bare Metal Recovery Using the Plug-in Offline Client
Plug-in Server: an overview Installing and removing Plug-in Server Configuring Plug-in Server for use with Plug-in Offline Client Booting a NetVault Bare Metal Recovery Client with Plug-in Offline Client Backing up data with Plug-in Offline Client Restoring data with Plug-in Offline Client
Using NetVault Bare Metal Recovery Plug-in Live Client
Plug-in Live Client overview Configuring Plug-in Server for use with Plug-in Live Client Installing and removing Plug-in Live Client Backing up data with Plug-in Live Client Booting a NetVault Bare Metal Recovery Client with Plug-in Offline Client Restoring data with Plug-in Live Client
Using NetVault Bare Metal Recovery Plug-in Live Client for Linux
Plug-in Live Client for Linux: an overview Installing and removing Plug-in Live Client for Linux Generating a DR image for use with Plug-in Live Client for Linux Creating the required bootable CD for use with Plug-in Live Client for Linux Recovering a DR image for use with Plug-in Live Client for Linux
NetVault Bare Metal Recovery physical-to-virtual (P2V) recovery  Troubleshooting

"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:

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.
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.

2
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.
7
Use a text editor to open the “grub.conf” file.
8
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.
9
10
Using the information noted in Step 3 and Step 4, change the UUID to the device partition name for all mount and swap partitions.
11
To change the device name to its UUID in the “grub.conf” and “fstab” files, run the following command:
12
Use a text editor to open the “grub.conf” and “fstab” files, and verify that the device names were replaced with their corresponding UUIDs.
13
Make a backup copy of “/boot/grub/grub.conf” and “/etc/fstab”.
14
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”.
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

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택