A live browse operation gets information about files and folders during browse and restore operations.
To browse and recover files, you must have information about the files and folders included in a backup (metadata). This file metadata can be provided in the following ways:
-
Discovering file and folder information dynamically during the browse operation. This capability is known as Live Browse. Live Browse is used when file and folder metadata is not available for a backup.
Note
This method was originally introduced as a feature called Live File Recovery for VMware restores. It is now the default method for guest file and folder restores for all hypervisors.
-
Collecting file and folder information during the backup (not recommended).
Live browse with block-level reads is replacing metadata collection as the default mechanism for browse and restore operations.
Live browse can be used for both Windows and Linux virtual machines. To read data for advanced Linux file systems, a Linux access node can be used to browse and restore data from backups of Linux guest VMs.
The Linux access node provides UNIX file system support for ext2, ext3, ext4, XFS, JFS, Btrfs, HFS, and HFS Plus. To enable extended file system recovery for UNIX-based virtual machines, deploy a Linux access node or convert a Linux MediaAgent to a Linux access node.
Note
On MediaAgents and VSA Linux access nodes used for Live file browse and restore or File indexing operations, set event_activation to 0 in /etc/lvm/lvm.conf
Use a Windows MediaAgent to perform a live browse operation for Windows guest VMs. When you use a Windows MediaAgent for a live browse operation, information for FAT, FAT32, NTFS, and Resilient File System (ReFS) file systems is available.
You can use a Linux MediaAgent to perform a live browse operation for Windows guest VMs. The live browse for ReFS and dynamic disks is not supported.
If antivirus software is installed on VSA proxies or MediaAgents, specify exclusions for Commvault files and folders. Otherwise, the time required to browse and recover files might increase significantly.
Note
-
Live file recovery is only supported for recovery from backups using magnetic disk/cloud libraries, and is not supported from backups to tape libraries or virtual tape libraries.
-
The Multipath Input Output (MPIO) must be disabled for CVLT disks. For more information, see Disable the Multipath Input Output (MPIO) for Commvault disks.
-
If you have a Windows proxy that is configured at the instance or subclient level, you can use this proxy for live browse and disable it during backup operations. To do this, add the nStreamLimit additional setting to the proxy, and apply the value of -1. For more information, see the following topics:
Block-Level Browse
Block-level browse enables users to browse and recover files without requiring metadata collection during backup. Block-level browse is supported for streaming backups for all hypervisors, and for IntelliSnap backups for VMware and Nutanix AHV. As noted below, some hypervisors still provide the option to collect metadata during backups to enable file browsing and recovery.
Block-level browse uses a block-level driver to mount a pseudo disk on the MediaAgent being used for browse and restore operations. The pseudo disk is used to get file system information, enabling browse and restore operations to read directly from stored backup data, without relying on content indexing.
Block-level browse replaces 3DFS Live Browse and is used as the underlying mechanism for the following features:
-
Application aware backups
-
Live browse
-
Live file recovery
For Windows guest VMs, the Windows MediaAgent that is used for browse and restore operations must have the Virtual Server Agent installed.
For Linux guest VMs, a Linux access node can be used to browse and restore data from backups of Linux guest VMs.
To stage extents for block-level live browse operations, the block-level browse feature uses a Least Recently Used (LRU)-based pseudomount cache in the job results directory. The pseudomount cache is pruned periodically to free up extents.
Block-level browse uses 10% of the system's available memory and dynamically adjusts memory usage per the system's available memory. For example, if the system's available memory is 450 GB, then block-level browse uses 45 GB. During a block-level browse operation, if the system's available memory reduces to 300 GB, then block-level browse uses 30 GB.
|
System RAM |
Pseudomount cache (min) |
Pseudomount cache (max) |
|---|---|---|
|
< 8 GB |
~650 MB |
10% of available memory |
|
8 GB–16 GB |
~1162 MB |
10% of available memory |
|
16 GB–32 GB |
~1668 MB |
10% of available memory |
|
> 32 GB |
~4228 MB |
10% of available memory |
Restrictions:
-
Unless otherwise noted for a particular feature, block-level browse (also called live browse) and block-level restores are not supported from backups to tape libraries or virtual tape libraries.
-
Block-level browse is not supported on VM disks that have a mount point instead of a drive letter.
-
Due to a Microsoft limitation, block-level browse is not supported on ReFS volumes if the MediaAgent used for the browse is running on a Microsoft 2008 R2 server or earlier version.
-
For files stored on Windows Storage Spaces, you can perform a block level browse to view and restore guest files and folders, with the following considerations:
-
The VSA proxy and MediaAgent that are used for the block level browse must be running on Windows Server 2012 or later.
-
For a Windows 2016 guest VM, you must use a VSA proxy and MediaAgent that run on Windows 2016 or later.
-
The MediaAgent that is used for the block level 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.
-
Block level browse of Windows storage spaces is only supported for streaming backups, auxiliary copies, and backup copies, and not directly from IntelliSnap backups.
-
-
Disable the Multipath Input Output (MPIO) for Commvault disks.
Automatic Installation of Virtual Server Agent or MediaAgent
Commvault automatically installs the Virtual Server Agent or the MediaAgent when those packages are required for an operation:
-
When a live browse is performed, to access file and folder information for a virtual machine backup that does not contain metadata, the Virtual Server Agent is automatically installed to the MediaAgent that is used for the browse operation.
-
When a live browse for a Windows guest VM uses a Linux MediaAgent and the VSA proxy that is used for the live browse does not have the MediaAgent package, Commvault automatically installs the MediaAgent on the VSA proxy.
The remote installation restarts CVD services on the MediaAgent or VSA proxy and does not check for running jobs being handled by the MediaAgent or VSA proxy. As a result, jobs that were running might go Pending. After the install software job completes, any affected jobs restart automatically.
To disable automatic installations, configure the DisableAutomaticPushInstall additional setting.
-
To the CommServe computer, add the DisableAutomaticPushInstall additional setting as shown in the following table.
For instructions about adding the additional setting from the CommCell Console, see Adding or Modifying Additional Settings from the CommCell Console.
Property
Value
Name
Category
CommServDB
Type
Integer
Value
1
Note
If the automatic installation of packages to clients is disabled, some on-demand features may not work as expected.
Cloud Library Support for Live Browse
For all VSA hypervisors that support live browse, you can perform live browse operations with the following cloud libraries:
-
Amazon S3: S3 Standard storage class
-
Google Cloud Storage: Region or multi-region storage class
-
Microsoft 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