Live Browse and Recovery of Guest Files and Folders for VMs

A live browse operation gets information about guest files and folders during a restore operation. The information about the files and folders included in a backup is discovered during the browse operation as you select the content to restore.

File System Support

You can perform restores of guest files and folders from backups of Windows VMs that use NTFS, Resilient File System (ReFS), FAT, and FAT32 file systems, and of Linux VMs that use ext2, ext3, ext4, XFS, JFS, HFS, HFS Plus, or Btrfs file systems.

To enable extended file system support for Linux VMs, you must deploy and use a Linux access node to access the data in the backups.

The Commvault software automatically selects a Windows or Linux MediaAgent for live file browse of Windows or Linux guest VMs. If a Windows MediaAgent is not available, then the software uses a Linux MediaAgent where the backup data resides.

• If a Windows MediaAgent is used for live browse, then information for FAT, FAT32, NTFS, and ReFS is available.

• If a Linux MediaAgent is used, then live browse for ReFS and storage spaces is not supported. To live browse a dynamic disk, the Linux MediaAgent must have the Virtual Server Agent.

Cloud Storage Support

Live browse operations are supported for VM backups that reside on the following cloud storage:

• Amazon S3: S3 Standard storage class

• Google Cloud Storage: Region or multi-region storage class

• Azure Storage: Default container storage using hot or cold access tiers with General Purpose v1 (GPv1) or General Purpose v2 (GPv2) storage account

• Oracle Cloud Infrastructure (OCI) Object Storage

Cloud Archive Storage Support

For backups that reside on a cloud archive storage, the Commvault triggers a staging restore job when you initiate a guest files and folders restore, which triggers the cloud recall workflow. The backup content is recalled from the archive tier to the hot tier. After the staging restore job completes, the backup content is available for browse and restore.

For supported cloud tiers, see Restoring Data from Archive Cloud Storage - Supported Archive Cloud Storage Platforms.

The retention and re-archiving of data from the hot tier is hypervisor dependent. For information about the workflow, which is triggered automatically and doesn't need to be run manually, see Running the Cloud Storage Archive Recall Workflow On-Demand.

Tape Storage Support (Supported for Hyper-V and VMware Only)

For backups that reside on a tape storage, the Commvault triggers a staging restore job when you initiate a guest files and folders restore. The backup content is staged to the Live Browse Cache (LBC) on the MediaAgent associated with the tape storage. After the staging restore job completes, the backup content is available for browse and restore.

If the size of the LBC is less than the size of the backup content, then the staging restore job is not triggered. Ensure that sufficient disk space is available to stage the backup content.

Considerations

• Verify that the MediaAgent has the Virtual Server Agent installed, and has access to the library and media that are required for the restore operation.

• Browsing fails if the file system on the source VM for the backup is not supported by the Linux access node. Browsing speed is affected by network latency and the complexity of the file system being browsed.

• Initial mount during browse may take time if the VM snapshot contains an inconsistent file system that requires fsck (file system check). A restore that follows the browse in quick succession does not incur that overhead because it reuses the mount point.

• If there is no activity on the VM for a specified time (by default, 10 minutes), the browse times out and the VM is unregistered. Once the cleanup is done, the restore job is marked as Completed.

• When restoring large volumes of guest files and folders ranging from 100s of GBs or more than one TB, Commvault recommends that you perform the Attach disk to VM restore to existing VM or another VM. Copy the required data and then delete the attached disk.

• For the fastest recovery of guest files and folders and minimal space usage for extent caching, use live browse and recovery with a restore-only file system agent on the destination VM.

• Live browse and restore is not supported if the VM encryption is enabled with Virtual Trusted Platform Module (vTPM) and if volumes are encrypted using encryption software (for example, Bitlocker).

Linux Guest VMs

• For Linux guest VMs, a Linux access node and MediaAgent can be used to browse and restore data from backups of Linux VMs.

• When used with agentless restores, the Restore ACLs option only restores basic user/group/world permissions and timestamps. Advanced permissions are only restored when using a guest agent together with a Linux access node.

• When you perform a live browse operation on Linux files and folders, all mountable file systems are listed as individual disks. Any LVM logical volumes from the source VM are shown by name, using the naming convention VolumeGroupName-LogicalVolumeName rather than the mount paths that are used in the source VM.

• Logical volume manager (LVM) metadata processing for volumes encrypted using encryption software is currently not supported. Decrypting contents of such volumes may not be feasible during browse or restore operations because decryption requires a recovery password or a decryption key. As enumeration for the volume fails, a file-level browse operation for the encrypted volume cannot display file information.

• Permissions for guest files and folders are retained only when the user running the restore operation has permissions to change group ownership on the restored files and folders. If the user does not have change group ownership permissions, the restored files and folders are owned by the user who performed the restore.

• You cannot restore an empty folder unless you restore the parent folder. When you restore a parent folder all other folders contained in the parent folder are also restored.

• Some special files from Linux systems cannot be restored to a Windows system. These include symbolic link files, socket files, character device files, block files, and pipe files (FIFOs).

• Symbolic links can be restored if the source files are also restored, but they will use the timestamp of the restore operation instead of the original timestamp. If the source files are not restored, symbolic link files are restored but without links; as a result the linked data cannot be read.

• Hard link files can be restored. If source files are also restored, then any corresponding link files use the same index node (inode).

• For Linux and Windows file restores, the Commvault selects the most suitable access node. For Linux file restores, that means that, if the Preferred node for guest file restores setting is set for the hypervisor, then Commvault uses that access node. However, if the operating systems of the access node and the guest VM aren't compatible, Commvault uses a compatible access node. For example, if the preferred access node runs Red Hat Enterprise Linux (RHEL) 8.x and the guest VM runs RHEL 9.x, then the Commvault uses an access node that runs RHEL 9.x.

• When you perform a live browse for a Linux guest VM, the directory hierarchy displays results for each guest VM using the same root directory structure as the source VM, and are restored using the same folder structure. Mounted devices are shown in the directory structure according to the following rules:

  • If a device is present in the source VM under the /etc/fstab folder with the device UUID or logical volume name, the live browse results show the device in the same location.

  • If a device cannot be located in the root file system and the device is a raw disk, the live browse results show the device under the /cvlostandfound/blkuuidOfDevice directory.

  • If a device cannot be located in the root file system and the device is a logical volume, the live browse results show the device under the /cvlostandfound/vgname-lvname directory.

Windows Guest VMs and Storage Spaces

• For Windows guest VMs, ensure that the Virtual Server Agent is installed on the Windows MediaAgent used for browse and restore operations.

• The MediaAgent that you use for live browse operations of an ReFS volume must support the version of the ReFS volume on the guest VM. For example, to live browse and restore files from an ReFS volume from a backup of a Windows Server 2016 VM, you must use a MediaAgent running on Windows Server 2016 or later. To browse and restore files from an ReFS volume from a backup of a Windows Server 2019 VM, use a MediaAgent running on Windows Server 2019 or later.

• To browse and recover files from a guest VM running Windows 2016, 10 or 11, you must use a VSA access node and MediaAgent that runs on Windows 2016 or later.

• Use live browse and recovery to restore files that have been dehydrated by Windows deduplication. The Windows version of the VSA access node and MediaAgent must be the same as or later than the Windows version of the VM for which files are being restored. For example, a MediaAgent running Windows Server 2016 or later, with the Virtual Server Agent installed and with the Windows deduplication role enabled, must be used as the VSA access node when restoring dehydrated files from a Windows Server 2016 VM.

• The MediaAgent that is used for the live browse cannot be part of a clustered environment.

• Dynamic disk configuration on the virtual disk for a storage pool is not supported.

• You cannot simultaneously browse two cloned VMs that use the same storage space information.

• Live browse of Windows storage spaces is only supported for streaming backups, auxiliary copies, and backup copies, and not directly from IntelliSnap backups.