Loading...

Live Browse, Block-Level Browse, and Metadata Collection

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

  • 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 UNIX virtual machines. To read data for advanced UNIX file systems, a File Recovery Enabler for Linux can be used to browse and restore data from backups of UNIX VMs.

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

Changes in Metadata Collection for Service Pack 11 and Later

The Enable Granular Recovery option has been removed from the Advanced Backup Options dialog box for all hypervisors.

For hypervisors that support metadata collection, the following option is now available in the Subclient Properties dialog box:

  • Collect File Details: On the Backup Options tab, for streaming backups and backup copies.
  • Collect File Details for Snapshot Copy: On the IntelliSnap Operations tab, for IntelliSnap backups. Use this option when creating a copy for tape storage, because file and folder information is required when recovering files from tape.

By default, these options are not enabled for any subclients. This reduces the time required to perform backups.

You can use live browse to view and recover guest files without collecting file information during backups.

For upgraded clients, the settings for these options reflect the configuration of existing backup schedules for each subclient. If an existing backup schedule explicitly selected the Enable Granular Recovery option, the Collect File Details option is enabled for the corresponding subclient.

For upgrades from a previous service pack, the following additional considerations apply:

  • If the CommServe system was upgraded to SP11 but the VSA proxy is still using an earlier service pack, the schedule shows the previous selection for the Enable Granular Recovery option and scheduled backups honor that setting. However, if you initiate a backup manually from the subclent, the resulting backup does not collect metadata, regardless of the subclient setting. To avoid this behavior, upgrade the VSA proxy to SP11.
  • If different schedules existed for a subclient prior to an upgrade to SP11, with different settings for the Enable Granular Recovery option, the subclient has the Collect File Details option set after the upgrade to SP11. However, when the schedule that did not select the Enable Granular Recovery option runs, file information is collected because that option is controlled by the subclient setting. The best practice is to use separate subclients for VMs that require metadata collection during backups.

Option to Collect File Details During Backup

The following table shows which hypervisors include the Collect File Details option.

Note: The Collect File Details option enables a backup operation to collect file and folder metadata only for NTFS, ext2, and ext3 file systems. Backup operations cannot collect file and folder metadata for other file systems.

By default, metadata is not collected for streaming backups, IntelliSnapbackup copies, orIntelliSnap backups.

Hypervisor

Is the Collect File Details option available for subclients?

Is metadata collected by default during backups?

Is block-level browse used for file recovery?

Amazon

No

No

Yes

Citrix Xen

Yes

No

Yes (if metadata was not collected during backup)

Docker

No

No

No

Huawei FusionCompute

No

No

Yes

Microsoft Azure

No

No

Yes

Microsoft Hyper-V

Yes

No

Yes (if metadata was not collected during backup)

Nutanix Acropolis Hypervisor (AHV)

No

No

Yes

OpenStack

No

No

Yes

Oracle VM

No

No

Yes

Red Hat Virtualization

No

No

Yes

VMware

Yes

No

Yes (if metadata was not collected during backup)

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 File Recovery Enabler for Linux can be used to browse and restore data from backups of UNIX 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. The pseudomount cache requires up to 20 GB of free space for restore jobs of any size.

Note: For Windows guest VMs, pruning might not occur. Ensure that space is available up to the total size of data being restored.

For block-level restores, in addition to the restore job, the Job Controller launches a persistent recovery job that opens a common pipeline, enabling multiple extent recall requests to be submitted as a group. The default timeout for a persistent recovery job is 24 hours. For block-level restores using the Virtual Server Agent, the persistent recovery job remains open for 24 hours and can be used for subsequent block-level restores that use the same proxy.

Restrictions:

  • Unless otherwise noted for a particular feature, block-level browse (also called live browse) is 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.

Block-Level Browse for Large Disks

To perform a block-level browse for disks that are 16 TB or larger, take the following actions:

  • Create a new disk on the MediaAgent and format it with an NTFS cluster size of 8 KB (to live browse a disk of 16 TB to 32 TB) or 16 KB (to live browse a disk of 32 TB to 64 TB).

    Provide at least 100 GB of space for the new disk on the MediaAgent. This disk is used to stage data during the block-level browse operation. Extents are pruned using the Least Recently Used (LRU) algorithm, which might result in an additional recall for some data.

  • Change the path of the Job Results folder to use the new disk.

During a live browse, a sparse file with size equal to the source volume is created to stage the recalled extents. NTFS volumes with allocation unit size less than 64 KB do not support the creation of sparse files greater than 16TB. For more information on supported volume size and allocation unit size, see Microsoft KB article Default cluster size for NTFS, FAT, and exFAT.

Windows Storage Spaces Requirements

For files stored on Windows Storage Spaces, you can perform a live browse to view and restore guest files and folders, with the following considerations:

  • The VSA proxy or MediaAgent that is used for the live browse must be running on Windows Server 2012 or later.
  • 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.

Automatic Installation of Virtual Server Agent

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.

The remote installation restarts CVD services on the MediaAgent and does not check for running jobs being handled by the MediaAgent. As a result, jobs that were running on the MediaAgent might go Pending. After the install software job completes, any affected jobs restart automatically.

To disable the automatic installation of the Virtual Server Agent to MediaAgents, 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

DisableAutomaticPushInstall

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.

UNIX File System Support

For UNIX VMs, you can enable browse and restore operations for UNIX file systems (ext2, ext3, ext4, XFS, JFS, HFS, HFS Plus, and Btrfs) by converting a Linux MediaAgent to act as a File Recovery Enabler. For hypervisors that support Linux proxies, the Virtual Server Agent role can also be enabled on the MediaAgent.

For Commvault Service Pack 7 and later, MediaAgents that are able to act as File Recovery Enablers are automatically configured.

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
  • Google Cloud Storage
  • Microsoft Azure Storage

Live Browse with Linux MediaAgents

For Service Pack 11 and earlier service packs, if the MediaAgent for a live browse operation is running on Linux, the operation replaces the MediaAgent with a VSA proxy running on Windows:

  • If a Windows proxy is included on the proxy list for the instance or subclient, the live browse uses that proxy instead of the default MediaAgent. The MediaAgent role must be enabled on the Windows proxy.
  • For Service Pack 11 and later service packs, if no Windows proxies are available for the instance or subclient, the live browse uses the CommServe system. The Virtual Server Agent and MediaAgent packages must be installed on the CommServe system.

    Note: On the Commvault HyperScale Appliance, the CommServe software and the Virtual Server Agent and MediaAgent packages are pre-installed. If you are using a CommServe system on the HyperScale Appliance, you do not need to perform any additional configuration to enable live browse operations using VSA proxies and MediaAgents running on Linux machines.

To avoid falling back to a Windows proxy or the CommServe system, you can specify a Windows MediaAgent for a browse operation. From the Browse and Restore Options dialog box, click the Advanced Options tab and select a Windows MediaAgent from the Use MediaAgent list.

Last modified: 10/8/2019 3:02:28 PM