Linux file restore operations limitations

Edit online

Consider the following known Linux platform issues and limitations for file restore operations issued from the IBM Storage Protect file restore interface while troubleshooting.

Support volume types

The Linux mount proxy system can mount and support volume types such as EXT2, EXT3, EXT4, REISERFS, XFS, BTRFS, RAID device, and LVM device. Using volume types that are not supported by the Linux mount proxy system results in failure of mount operation and the following error message is displayed:
ANS3141W Mounting the following device failed: Volume not supported.

Directories that are created (or recreated) during a restore operation might be assigned incorrect access permissions, ownership information, or both

Upon a successful restore operation, the original user access permissions and ownership information of the restored files is preserved. However, access permissions and ownership information of the recreated directories (if any) change in accordance with the default umask setting and the initial login group of the user that is logged in for restore on the target Linux system. This is a known limitation.

Linux temporary file system supports file restore to alternate location only

A Linux file system that is mounted in the guest virtual machine, but is not present in the /etc/fstab system configuration file, supports a file restore to alternate location operation only. It does not support a file restore operation to the original location. In this scenario, it does not matter whether the file system is listed in the /etc/mtab file.

A Linux file system that is mounted in the guest virtual machine, but is not present in the /etc/fstab system configuration file, is represented in the file restore user interface as volume#. This is a known limitation.

In this scenario, a Red Hat Enterprise Linux (RHEL) 6.5 mount proxy system attempts to mount volumes from an RHEL 7.1, SLES 11, or SLES 12 virtual machine. The operation fails and the mount proxy system reboots. This scenario occurs because a Linux mount proxy system cannot mount Btrfs or XFS volumes from a virtual machine with a later Linux operating system. This is a known limitation.

To prevent this situation, ensure that the minimum level of the Linux mount proxy system is at the same level, or later level, than the level of the protected guest virtual machine.

Linux mount proxy system cannot mount volumes from a virtual machine with a later Linux operating system

In this scenario, a Red Hat Enterprise Linux (RHEL) 6.5 mount proxy system attempts to mount volumes from an RHEL 7.1, SLES 11, or SLES 12 virtual machine. The operation fails and the mount proxy system reboots. This scenario occurs because a Linux mount proxy system cannot mount Btrfs or XFS volumes from a virtual machine with a later Linux operating system. This is a known limitation.

To prevent this situation, ensure that the minimum level of the Linux mount proxy system is at the same level, or later level, than the level of the protected guest virtual machine.

Group identifier is not preserved during restore operation by a non-root user

When a non-root user restores a file that is owned by the same non-root user, the group identifier (GID) for this file is not preserved. This is a known limitation.

To preserve the GID for a file that is owned by a non-root user, restore the file by using root user authority.

Potential UUID collisions on Linux mount proxy system and guest virtual machines

File restore operations are not supported when UUID collisions occur. A UUID collision is defined as the mount proxy system has an identical UUID as the guest virtual machine being whose disks are being mounted. UUID collisions might occur between the guest virtual machines and the mount proxy system in any of the following scenarios:
  • The guest virtual machine is cloned from the mount proxy system.
  • The mount proxy system is cloned from the guest virtual machine.
  • The guest virtual machine and mount proxy system are cloned from the same template.
  • The guest virtual machine is cloned from a virtual machine that is already mounted on the mount proxy system.
When a UUID collision exists between the guest virtual machine and the mount proxy system, a file restore operation cannot identify the original restore points on the mounted guest virtual machine. In this situation, the volumes related to the duplicated UUIDs are skipped. Before using the file restore interface, be sure to resolve any UUID collisions between the mount proxy system and guest virtual machines in Linux. Engage your Linux administrator, or Linux support, for guidance.
The following example shows how to generate a new UUID in most file systems, but not all file systems. The workaround is not valid for Btrfs files systems. Ensure your Linux administrator, or Linux support, validates the steps necessary to generate a new UUID for the file systems in use on either the guest virtual machine or mount proxy system.
  1. Generate a new UUID on the cloned system by running the uuidgen command.
  2. Assign the new UUID to a specified block device on the cloned system by running the tune2fs command with the -U option (tune2fs <device> -U <new_UUID>).

LVM devices are not mounted if the LVM importing tool is not able to generate a new UUID

On some Linux distributions, it has been observed that the vgimportclone command is not able to assign a new UUID to the device. This results in duplicated device UUIDs on the mount proxy machine. In this situation, the volumes related to the duplicated UUIDs are skipped and the ANS3184W message is reported in the TSM log file. This could be a signal that the guest virtual machine is a clone of the mount proxy system. See also the above section, Potential UUID collisions on Linux mount proxy system and guest virtual machines.

Linux Mount Proxy lvmetad daemon may activate the LVM volumes before it is activated by the IBM Storage Protect for Virtual Environments services

This behavior causes the file level restore process not to mount one or more guest filesystem(s) without the mount process issuing any warning or error message. To avoid that, the steps to disable it on the Linux Mount Proxy host are as follows:
  1. Edit the /etc/lvm/lvm.conf file to set the parameter use_lvmetad to 0.
  2. Run the following administration commands:
    • systemctl stop lvm2-lvmetad
    • systemctl disable lvm2-lvmetad
    • systemctl stop lvm2-lvmetad.socket
    • systemctl disable lvm2-lvmetad.socket

Linux file restore operations limited to a maximum overall path length of 4096 characters

The overall path for the mount in the file restore interface is composed of the following objects:
/tsmmount/FLR/<VMName>/<SNAPSHOT_DATE>/VolumeX/dir1/dir2/dir3/dir4/dir5/fileName
The maximum path length for the mount in the file restore interface is determined by the total number of combined characters for each object that compose the path of the mount:
  • /tsmmount/FLR/<VMName>/<SNAPSHOT_DATE>/VolumeX: Maximum length of the mount path: 38 characters.
  • <VMName>: Maximum length of the virtual machine name: 80 characters.
  • fileName: Maximum length of the file name to be restored: 255 characters.
  • dir1/dir2/dir3/dir4/dir5: Maximum length of the path to the file to be restored is determined by the following formula:
    • 4096
    • - length of mount path (38)
    • - length of virtual machine name (80)
    • - length of file name to be restored (255)
    • = Maximum length of the path to the file to be restored
If the total number of combined characters for the path of the mount exceeds 4096 characters, the file is skipped and the restore operation continues for other selected files and directories. No message displays to identify files that are skipped.

If a Linux virtual machine is included in file restore operations, make sure that the total number of combined characters for the path of the mount does not exceed 4096 characters.

Directory does not restore to alternate location on Linux virtual machine

In this scenario, a directory is selected for a Restore to > Alternate Location operation. After the operation completes, the following error message displays for the directory:
You do not have permission to restore the file to the destination folder.
This error occurs when either of the following conditions exist:
  • The directory has the same name as a file that was selected for restore.
  • The directory has the same name as a file that exists on the target virtual machine.
This is a known limitation.

SUSE Linux Enterprise Server 12 Btrfs subvolumes are not supported

By default, SUSE Linux Enterprise Server 12 uses Btrfs subvolumes for the root partition. During a file restore operation, the default subvolume is mounted as the root partition. However, Btrfs subvolumes such as /home, /usr, or /opt, are excluded from the snapshot and do not display in the file restore interface. As a result, Btrfs subvolumes are not supported for file restore operations.

A deleted Linux file system restores to the root directory

In this file restore scenario, a Linux file system (on the guest virtual machine) is unmounted and the file system mount point is deleted. A subsequent attempt to restore the file system restores the file system data to the root (/) file system. This issue occurs because the file system to restore is unmounted. As a result, only the mount point is recreated, and the data is restored to that directory under the root (/) file system.

Linux SLES 11 mount proxy system cannot mount Btrfs or XFS file systems from a Linux SLES 12 guest virtual machine

This environment consists of a SUSE Enterprise Linux 11 (Service Pack 3) mount proxy system, and a SUSE Enterprise Linux 12 guest virtual machine. In this scenario, the SUSE Enterprise Linux 11 mount proxy system cannot mount files from a SUSE Enterprise Linux 12 Btrfs or XFS file system. The mount operation fails and the following message displays:
An error occurred while loading the backup ...

Local user authentication is required for a virtual machine

Make sure that the user who authenticates to the Linux virtual machine that contains the files to be restored is a local user. Authentication is not available through Windows domain, Lightweight Directory Access Protocol (LDAP), Kerberos, or other network authentication methods.

File restore operations from a local VVOL snapshot require a free loop device for each of the guest virtual machine

Old Linux distributions have a limited number of default loop devices and this can limit the number of virtual machines that can be mounted on the mount proxy system. For some distributions, this number is set to 8 or to 64. This number can be theoretically set to a maximum of 256 loop devices, but requires a reboot of the machine and for some Linux distributions, to recompile part of the kernel.

Installing the Linux mount proxy on old Linux distributions (for example, Suse 11) can limit the number of disks that can be mounted on the mount proxy for file restore VVOL operations. In this situation, the file restore operation is stopped and a cleanup is performed.

For example, if a machine has 8 loop devices and only 6 are free, it is not possible to mount a local snapshot of a machine with 7 or more disks.

Use a Linux distribution such as Suse 12 or Redhat 7.3 for the mount proxy. These distributions dynamically create the loop devices upon request.

File restore operations from a local VVOL snapshot create a temporary defunct dsmagent on the Linux mount proxy system

For each mount of a snapshot of a VMDK, a defunct dsmagent is displayed in the process list of the mount proxy. This is due to incorrect handling inside the VMware library. The defunct dsmagent is no longer displayed after the main dsmagent has stopped.