Live File Recovery

Live File Recovery provides expanded file system support, including ext4, and enables live browse of backup data without requiring granular metadata collection during backups. This option supports restores of files and folders from backups of Windows VMs and of UNIX VMs that use ext2, ext3, ext4, XFS, JFS, or Btrfs file systems.

Live File Recovery can also be used when reducing backup times is a priority. This is a tradeoff; using this feature reduces backup time but increases the time required to browse files and folders.

To recover files or folders from a backup, you can enable backup data to be mounted as a temporary NFS datastore that can be used to browse and restore file and folders.

You can perform a live browse operation or live file recovery operation without mounting the backup snapshot to an ESXi host.

Prerequisites

To browse and recover files from a guest VM running Windows 2012 R2, select a VSA proxy and MediaAgent that is Windows Server 2012 R2 or later.
To restore UNIX files for ext4, XFS, JFS, HFS, HFS Plus, or Btrfs file systems in addition to ext2 and ext3 files, you must deploy a Access Node and MediaAgent to access the data in the backup. See Deploying a Virtual Machine for UNIX-Based File Restores.
When performing a live browse or recovering files from a Linux VM that was backed up without using an ESXi proxy (proxyless backup), the Access Node and MediaAgent must have the iscsiadm utility installed. If not, the live browse fails with the following JPR:
```
Browse failed due to error while mounting virtual machine:Unknow error , error returned from FBR mount [iscsi-initator-utils is required but not installed on this client]
```
For Commvault Service Pack 7 and later, MediaAgent that acts as a Linux access node is automatically configured.
When you perform a live browse operation on Linux files and folders, the Client tab shows logical volumes as volume groups rather than mount paths.
The ESX server used to mount the NFS datastore for the browse and restore must meet the following requirements:
- Be able to resolve the Linux access node. To ensure connectivity, create a host file entry for the Linux access node on the ESX server.
- Provide support for the highest virtual machine hardware version supported for the environment.
Configure a Linux access node to use for UNIX-based file restores as described in Specifying the Preferred Linux Access Node for a Virtual Server Instance, and an ESX server to host the NFS datastore as described in Identifying the Proxy ESX Server.
To support Live File Recovery when the Virtual Server Agent and MediaAgent are deployed on different machines, the Virtual Server Agent must also be installed on the MediaAgent, even if a different MediaAgent is used for data movement. Otherwise, the MediaAgent is not included in the Use MediaAgent list in the Advanced Options tab of the Browse and Restore Options dialog box. You must provide data access for the MediaAgent in one of the following ways:
- The MediaAgent that performs the browse must have access to the library and media that are required for the restore operation.
- Enable the restore operation to use an alternative MediaAgent by performing the steps in Enabling File and Folder Restores from Backups Made Using UNIX MediaAgents.
To enable Live File Recovery even when the Collect File Details option is selected for a subclient, you can configure the nEnforceLivebrowse additional setting on the Virtual Server Agent (VSA) proxy.

Considerations

Live file recovery is only supported for recovery from backups using magnetic disk libraries, and is not supported from backups to tape libraries, virtual tape libraries or cloud archive copy with automatic recall.

To perform live file recovery from a cloud archive copy, you can manually run the Commvault Cloud Archive Recall workflow on-demand. For more information, see Restoring Data from Archive Cloud Storage.
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 some 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.
Some special files from UNIX systems cannot be restored to a Windows system. These include symbolic link files, socket files, character device files, block files, and pipe files (FIFOs).
Use Live File Recovery to restore files that have been dehydrated by Windows deduplication. The Windows version of the VSA proxy 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 2012 R2 or later, with the Virtual Server Agent installed and with the Windows deduplication role enabled, must be used as the VSA proxy when restoring dehydrated files from a Windows 2012 R2 VM.
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.
- You cannot simultaneously browse two cloned VMs that use the same storage space information.
To live browse and restore files from an ReFS volume from a backup of a Windows 2016 VM, you must use a MediaAgent running on Windows 2016 or later.
For Linux:
- 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.
- The Preserve Source Paths option is not supported when you are restoring files or folders from a virtual machine.
- 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.
- 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 any corresponding link files use the same index node (inode).
- The following file systems are supported when using a Linux access node:
  - ext2
  - ext3
  - ext4
  - XFS
  - JFS
  - Btrfs
  - NTFS
    Notes
    - For VM-Centric clients, file restores from multiple VMs of the same OS in the same restore job is not supported.
    - Live browse and file recovery operations are not supported for XFS realtime subvolumes.
    - With Service Pack 8 or later, live browse and recovery is supported for subvolumes of Btrfs file systems.

Restore Process

A Linux access node provides file based restore (FBR) support that enables viewing of UNIX files and folders by using Live Browse from a backup snapshot for the source VM, without requiring that granular recovery was enabled for the IntelliSnap backup.

When a backup is browsed to initiate a restore, the source VM is identified as Windows or non-Windows.

For non-Windows systems, the Linux access node supports browsing for files and folders in the backup snapshot for the VM.
The snapshot is mounted to a temporary VM that provides access to the files for the snapshot.
By default, files are restored to the access node used for the restore, but you can select the source VM or another VM as the destination.