Guide de l'administrateur cloud sur l'interface utilisateur Web NetBackup™

The following limitations and considerations exist for granular restore:

• If adequate space is not available on the target location, the restore operation fails before the copy operation begins.

• Until the old agent (preinstalled) service is not restarted, alternate host restore (GRT and application) of the LVM asset might fail. To support the recovery of LVM assets, you need to restart the older agents.

• Before running the protection plan created for granular restore on Virtual machines on cloud, ensure that you regenerate and set the disks' UUIDs when disks created from same snapshot are attached to the Virtual Machine on cloud. The /etc/fstab entry must also be updated with the new UUID.

• Granular restore can be performed with the help of VxMS indexing. VxMS indexing is applicable for all Snapshot Manager-supported file systems. VxMS indexing can be performed for Azure, Azure Stack Hub, AWS, OCI, and GCP.

  However, VxMS indexing is not supported for volumes or partitions created on software RAID devices. These volumes, or partitions, are skipped while indexing the file system.

• Host consistent snapshot is supported for the EXT2 file system only if it is mounted as read only.

• If any unsupported file systems are present on the host, the host can be added to the protection plan that is created for granular restore. The protection plans for granular restore have the Enable granular recovery for files or folders check box value set to true.

• During indexing, OS errors can occur while crawling files, directories, or other entries. These errors are ignored and the indexing operation continues. To restore the missing files, you must initiate the granular restore operations on the parent folder.

• When you create or mount a disk from the Windows VM, add the drive letter. This action ensures that the indexing operation can capture the correct drive letter.

• In some cases a mount point is not visible when you browse for files or folders from the recovery point. Consider the following reasons:

  • The "/" (root file system) is on an LVM, and:

  • The mount point is not directly related to "/" (root file system).

  In this scenario, search for the mount point from the right panel and then restore the files or folders successfully.

  Consider the following example. A disk is mounted on /mnt1/mnt2 where /mnt1 is any directory on the "/". (The root file system that is on the LVM setup.) mnt2 is a mount point inside mnt1. mnt2 is not visible in the tree on the left panel. However, you can search and restore files or folders inside the mount point.

• While restoring application or file systems from one OS version to another OS version, refer to the OS and application vendor's compatibility matrix. The restore of a file system from a higher version to a lower version is not recommended.

• A user group cannot restore a drive as a source to an alternate folder as the destination. A user group does not have the writer permission to create a new folder.

• The agentless connection cannot restore the encrypted file by Windows (or EFS) through a granular file-level restore (Restore files and folder option). However, you can restore the file through a volume-level restore and then decrypt the file.

• Files that are stored on a volume that is mounted on a folder (junction point) can be restored only if the underlying disk has the GPT partition layout. If the volume is mounted using a drive letter, then the files can be restored irrespective of the partition layout of the underlying disk.

• Consider a scenario where an alternate path that does not exist on the RHEL target host is specified for a single file restore. Then the new directories that are created are under the security context of the user under which the agent runs. The storage administrators must ensure that the final restore location is accessible to the required user.

• NetBackup does not support indexing of VMs having VHDX disks (Azure Ultra disks, Premium SSD v2 with a 4k sector size) and granular restore.

• When snapshots are performed or indexed, the following devices are ignored:

  • Ephemeral storage devices: For example, an Amazon AWS instance store volumes and Microsoft Azure temporary disks

    Remarque :

    These devices are also ignored for indexing also.

  • File systems that are created on the LDM disk.

    Remarque :

    Though the files/folders from the LDM disks are visible for selecting on Web UI during Single File Restore, the files would not be restored and the restore job would fail.

• Extended attributes would not be restored for Linux VM files.

• For FIPS setup, Single file restore for Windows to Windows is not supported.

• Linux VM single file restore: If a directory contains more than 100K files, restore of the directory and files inside the directory would be skipped due to a limitation in Instant Access mount.

• You must attach the block volumes after creating the VMs, and provide the consistent device path while attaching the volume.

• Granular restore from a snapshot copy and volume restore, require the block volume management plug-in to be enabled on the target VM. Restart the VM after enabling the plug-in.

• For Windows instances, granular restore from a snapshot copy is not supported.

• Granular restore from backup copy to an Windows instance, you need to manually copy the granules from the NFS share.

• Granular restore from a snapshot copy, from a boot volume to another boot volume is not supported for all operating systems.

• Granular restore from Linux OS not having consistent device paths are not supported, if the disks are attached as paravirtualized attachments.

• Granular restore from a source VM that has higher kernel version, to a target VM with lower kernel version is not supported.

• When you restore files and folders from a Linux source host and the target host is Windows, the following points apply:

  • File attributes cannot be restored on a Windows host and only the content of the file is restored.

  • If there is any symlink in the files or folders that are selected for restore, the symlink is not restored.

  • For a restore to the original location, the check for available size is skipped before the copy operation.

• If restoring files or folders when the source host is Linux and the target host is Linux, then the socket and the block files are not restored.

• A restore of files and folders is not supported when they reside on any LDM disks, dynamic disks, or storage spaces.

• If the media server or the PureDisk Deduplication Engine and Cohesity Provisioning file system daemon service restarts, the live mount that is retained during a partially successful restore is removed or expires before the retention period expiration date.

• If any media servers are not upgraded to 10.3 or later, then the primary server on version 10.3 or later is used to connect to NetBackup Snapshot Manager.

• The junction point on Windows after indexing uses the following format:

  Volume {4e3f8396-490a-400a-8abf-5579cafd4c0f}

  To restore a junction point for single file restore from backup operation, select Restore everything to a different location and in the Advanced options enable Require to restore access control list.

The following behaviors exist for the Activity monitor:

• After a restore job is completed, you cannot expand the directories in the File List section of the restore job.

• In the Activity monitor summary, when the restore job starts it shows the current file which is the first entry in the restore items. After the job is complete, the summary no longer displays.

• Bytes transferred and estimated bytes are not updated and are shown as 0.