Loading...

Block-Level Browse, Live Browse, and Metadata Collection

To browse and recover files, you must have information about the files and folders included in a backup. This file metadata can be provided in the following ways:

  • Discovering metadata 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.
  • Collecting metadata during the backup. Prior to SP4, this behavior was controlled by the Enable Granular Recovery in the Advanced Backup Options dialog box for hypervisors that supported file level recovery. With SP4 or later, file browse and recovery operations can be performed without requiring metadata collection during backups.

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  SnapProtect backups for VMware. 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
  • File Recovery Enabler for Linux

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

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.

Restrictions:

  • Unless otherwise noted for a particular feature, block-level browse is only supported for recovery from backups using magnetic disk libraries, and is not supported from backups to tape libraries or virtual tape libraries.
  • The maximum size of a VM disk allowed for browse is 15 TB.
  • Block-level browse is not supported on VM disks that have a mount point instead of a drive letter.
  • Metadata collection and live browse are not supported for Windows Storage Spaces. To retrieve guest files from Storage Spaces, restore the full virtual machine or virtual machine disk files.
  • 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.

UNIX File System Support

For UNIX VMs, you can enable browse and restore operations for UNIX file systems 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.

Default Settings for Metadata Collection and the Enable Granular Recovery Option

The following table shows which hypervisors include the Enable Granular Recovery option and indicates whether metadata is collected by default for streaming backups or SnapProtectbackup copies. (By default, metadata is not collected for SnapProtect backups.)

Hypervisor Is the Enable Granular Recovery option available in Advanced Backup Options? Is metadata collected by default during backups? Is block-level browse used for file recovery?
Amazon Yes Yes Yes
Citrix Xen Yes Yes Yes (if metadata was not collected during backup)
Microsoft Azure No No Yes
Microsoft Hyper-V Yes Yes 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

Note: The SP4 changes for metadata collection apply only to new backups or schedules. Existing jobs or schedules continue to use the options that were configured when the job or schedule was created.

You can create the CollectVSAGranularMetadata additional setting on CommserveDB.Console to change the default behavior. For example, the following string shows the values that describe the default settings for all hypervisors:

hyperv,xen,!amazon,!azure,!nutanix,!openstack,!oraclevm,!vmware,!redhat

Where ! indicates that metadata is not collected for backups. If a hypervisor is not listed in the string value for this additional setting, the default behavior applies.