About branch recovery
The branch recovery feature allows you to define the working data set of LUNs projected by Core. During a catastrophic and irrecoverable failure, you can lose access to the working set of LUNs. Branch recovery enables proactive prepopulation of the working set when the LUNs are restored.
The branch recovery feature enables you to track disk-accesses for both Windows LUNs and VMFS LUNs (hosting Windows VMs) and quickly recover from a catastrophic failure. During normal operations, the Edge caches the relevant and recently accessed user data on a working set of projected LUNs.
In event of catastrophic failure in which you cannot recover the Edge, the working set of projected LUNs is also lost. With branch recovery enabled, the working set is proactively streamed to the branch when a new Edge is installed and LUNs mapped. Branch recovery ensures that after the branch is recovered, the user experience at the branch does not change.
Do not confuse either regular prefetch or intelligent prepopulation with branch recovery. Branch recovery prepopulates the working set proactively, as opposed to pulling related data on access, as in the case of regular prefetch. Branch recovery is different from intelligent prepopulation because intelligent prepopulation pushes all the used blocks in a volume with no regard to the actual working set.
Branch recovery is based on Event Tracing for Windows (ETW), a kernel-level facility. Riverbed supports only Windows 7, Windows 2008 R2, Windows 2012, and Windows 2012 R2. Branch recovery is supported for both physical Windows hosts and Windows VMs. You must format physical Windows host LUNs with NTFS. For VMs, NTFS-formatted VMDK hosted on VMware VMFS LUNs are supported.
The following are the major components of branch recovery:
• Branch recovery agent
• Branch recovery support on Core
The branch recovery agent is a service that runs in branch on a Windows host or VM. The agent uses Windows ETW-provided statistics to collect and log all disk access I/O. Periodically, the collected statistics are written to a file that is stored on the same disk for which the statistics are collected for. The file is called lru*.log and is located in the \Riverbed\BranchRecovery\ directory.
You can download the branch recovery agent plugin from the Riverbed Support site as part of the Unified Installer for Riverbed Plugins. Turbo Boot can coexist with the Branch Recovery Agent. When both services are installed on the Windows Server they are automatically started at different intervals. This is by design but may result in the following message on the Windows Server until both services have started, “The NT Kernel Logger session is already in use. Failed to start ETW Controller: sleeping for 60 seconds.” The message can be ignored. For more information about the branch recovery agent, see the Core user guide.
You must enable branch recovery support for the LUN prior to mapping LUNs to the new Edge. When a VMFS LUN or a snapshot is mapped to a new Edge, the Core crawls the LUN and parses all the lru*.log files. If the files that are previously created by a branch recovery agent are found, the Core pushes the referenced blocks to the new Edge. The branch recovery agent sends the most recently accessed blocks first, sequentially for each VM. When data for a certain time frame (hour, day, week, or month) is recovered for one VM, the process moves on to the next VM in round-robin fashion, providing equal recovery resources to all VMs.