Data Protection and Snapshots

This chapter provides an overview of data protection, server-level backups, and data recovery. It also describes how Core integrates with the snapshot capabilities of storage arrays, enabling you to configure application-consistent snapshots through the Core Management Console. It includes the following sections:

For details about storage qualified for native snapshot and backup support, see the SteelFusion Core Installation and Configuration Guide.

For more information about deploying SteelFusion in a VMware environment using snapshots with data protection, see https://supportkb.riverbed.com/support/index?page=content&id=S27750.

Data protection can mean different things to different people. In the context of storage, using very simplistic terms, it is about ensuring your data is safe such that if the original data is lost in some way, another copy that you have backed up on alternative storage can be restored. This chapter aims to provide you with some general information about how SteelFusion can integrate with existing data protection strategies that you may have in place, but also offers additional tools and capabilities that could improve or even replace some of the existing approaches you may have.

SteelFusion 4.6 and later provide the ability to back up data using policies that have a VM-aware capability making it even easier to keep to best practices when protecting your data. This feature is discussed further in the section called “Snapshots and server-level backups” on page 83 . But to begin with, the next sections cover the subject of snapshots, which form the basis of a data protection strategy.

The SteelFusion system provides tools to preserve or enhance your existing data protection strategies. If you are currently using host-based backup agents or host-based consolidated backups at the branch, you can continue to do so within the SteelFusion context.

However, Core also enables a wider range of strategies, including:

The SteelFusion product family continuously synchronizes the data created at the branch with exports hosted in the data center. As a result, you can use the storage array at the data center to take snapshots of the export and thereby avoid unnecessary data transfers across the WAN. These snapshots can be protected either through the storage array replication software or by mounting the snapshot into a backup server.

Such backups are only crash consistent because the storage array at the data center does not instruct the applications running on the branch server to quiesce their I/Os and flush their buffers before taking the snapshot. As a result, such a snapshot might not contain all the data written by the branch server up to the time of the snapshot.

SteelFusion 5.1 and later provide support for data protection of VMware virtual machines (VMs) that include Edge Local exports as part of the VM. Since data written to local exports is not synchronized back to the data center, a different approach is needed in this scenario. Therefore, to protect these types of VM, the SteelFusion server-level backup feature is able to back up the VM that is resident on a projected export but will automatically exclude any local export that the VM is configured to use.

Prior to SteelFusion 5.1 in this scenario, the VM itself would be excluded from server-level backups as well as the Edge local export.

This option relieves the backup load on virtual servers, prevents the unnecessary transfer of backup data across the WAN, produces application-consistent backups, and backs up multiple virtual servers simultaneously over VMFS or NTFS.

In this option, the ESX server, and subsequently the Core, takes the snapshot, which is stored on a separately configured proxy server. The ESX server flushes the virtual machine buffers to the data stores and the Edge appliance flushes the data to the data center export(s), resulting in application-consistent snapshots on the data center storage array.

You must separately configure the storage array information on the Core and the proxy server for backup. For details, see the “Configuring the proxy host for backup” on page 83.

For details about data protection, backup strategies, as well as a detailed discussion of crash-consistent and application-consistent snapshots, see the SteelFusion Data Protection and Recovery Guide.

For a discussion of application consistency and crash consistency in general, see “Understanding crash consistency and application consistency” on page 25.

For more information about deploying SteelFusion in a VMware environment, using snapshots with data protection, see https://supportkb.riverbed.com/support/index?page=content&id=S27750.

This section describes the general procedures for configuring the proxy host for backup in ESXi environments.

In deployments where vCenter is used to manage ESXi hosts in general, note the following with respect to the ESXi proxy host.

• If there is a requirement to manage the ESXi proxy host with vCenter, then a different vCenter must be used than that which is managing ESXi within the Edge appliances.

The general process for configuring NFS file server storage arrays for backup is simply to use either the CLI or graphical user interface on the NFS file server and set the access permissions for the export that is to be mounted by the backup proxy.

For details, ask your account team about relevant technical marketing solution guides.

With SteelFusion version 4.6, the features related to snapshot and backup were enhanced from a LUN-based approach to provide for server-level data protection. With NFS/file deployments using SteelFusion version 5.0 and later, this style of data protection supports branch ESXi servers including both the ESXi server in the hypervisor node of the Edge as well as external ESXi servers installed on the branch office LAN that use datastores mounted via NFS from the Edge.

The feature is able to automatically detect virtual machines (VMs) that reside on vSphere datastores in exports projected from the Core, and remotely mounted from Edge via NFS. This means that any VM resident on local ESXi datastore, or local storage provided by Edge (not projected by Core), will be filtered out and automatically excluded from any Core backup policy.

This exclusion also applies to VMs that may be on projected exports but are configured to use additional storage on Edge local exports. However, with SteelFusion 5.1 and later, server-level backups are further enhanced so that they are able to protect this type of VM by automatically excluding the local export.

Server-level backup policies are dynamically updated when VMs are added to, or removed from, ESXi servers that are included in the policy.

By default, the policies are designed to protect the VMs in a nonquiesced state. If backups are required on VMs that are quiesced, this can be enabled by editing the policy using a CLI command on the Core.

In this command, <group-id> is the name of the policy protection group identifier, and <VM1>, <VM2> are the VMs to be quiesced. For more details on this command, see the SteelFusion Command-Line Interface Reference Manual.

Note: Although the server-level backup feature is designed to protect physical Windows servers, this is only supported with SteelFusion deployments in block storage mode.

As part of the entire SteelFusion data protection feature, snapshots performed under the control of a server-level backup policy configured on the Core are protected by mounting the snapshot on a proxy server and backing it up using a supported backup application. This action is also performed automatically as defined by the schedule configured in the backup policy.

Remember, with a SteelFusion NFS/file deployment, backups are performed at the server level only. Individual VMs that are residing in the fileshare are exported from the Edge. Within an exported fileshare there may be a number of directories and subdirectories as part of the ESXi datastore, which may contain data other than the VMs themselves. This data is not included within the server-level backup policy defined on the Core.

It is possible to manually trigger a snapshot of the entire fileshare export using the SteelFusion Edge Management Console. This will cause a crash-consistent snapshot of the relevant fileshare to be taken on the backend NFS file server located in the data center. To achieve this, the Core must already be configured with the relevant settings for the backend NFS file server so that it can complete the snapshot operation requested by the Edge.

To specify these settings, in the SteelFusion Core Management Console choose Configure > NFS: Storage Arrays and select the Snapshot Configuration tab. An example screenshot is shown in Figure 6‑1 showing the required details for the NFS file server.

In the scenario where a manually triggered snapshot of the entire exported fileshare is taken on the backend NFS file server in the data center, because it is not part of any SteelFusion server-level backup policy, it is not automatically backed up. Therefore, additional third-party configuration, data management applications, scripts or tools, external to Core may be required to ensure a snapshot of the entire NFS-exported fileshare is successfully backed up. However, it is highly likely that such processes and applications are already available within the data center.

If you manually trigger snapshots by clicking Take Snapshot in the SteelFusion Edge Management Console and the procedure fails to complete, check the log entries on the Edge. This is especially relevant if the backend NFS file server is a NetApp.

If there are error messages that include the text “Missing aggr-list. The aggregate must be assigned to the VServer for snapshots to work,” see this Knowledge Base article on the Riverbed Support site:

https://supportkb.riverbed.com/support/index?page=content&id=S28732

This article will guide you through some configuration settings that are needed on the NFS file server. For more details, see the SteelFusion NetApp Solution Guide on the Riverbed Splash site.

See the SteelFusion Core User Guide for more details on snapshot and backup configuration.

The server-level backup policy wizard is a quick and simple way to configure server-level backup policies using best practices for data protection in a SteelFusion deployment. The wizard is designed to ensure that the correct scope (relevant exports and proxy) is applied for each server, whether it is a specific server or an Edge hosting multiple servers.

A protection group (Figure 6‑2) is the underlying construct that Core uses to map the server, VMs, and exports that are being protected. It contains the information associated with the backup policy, the server that is being protected, and the proxy host used for the backup.

A protection group is mapped to a particular server. This mapping applies to each server instance that exists in a backup policy, whether the policy is for an individual server or for an Edge that has multiple protected VMs.

You can view the protection groups from the CLI on the Core by using the following command:

Here is some sample output:

Occasionally, it may be necessary to customize a policy. For example, an Edge may have five VMs but it is required only to protect a selection of the VMs. Configuring a policy for the Edge using the wizard will automatically ensure all five VMs are protected on the Edge as a best practice.

Once the policy is created, you can modify it using the CLI on the Core. Using our example of the Edge with five VMs, you could modify the policy so that only two of the five VMs are protected. Alternatively, a slightly different syntax to the same command could be used to exclude two of the five VMs from being protected.

There are additional options for this command that allow modification of other policy parameters such as quiesce lists and backup history.

For more details on the use and syntax of the CLI commands used for protection groups, see the SteelFusion Command-Line Interface Reference Manual.

In the event your data protection strategy fails, the SteelFusion product family enables several strategies for file-level recovery. The recovery approach depends on the protection strategy you used.

This section describes the following strategies:

When snapshots are taken at the branch using Windows VSS in conjunction with RHSP, each snapshot is available to the Windows host as a separate drive. In order to recover a file, browse to the drive associated with the desired snapshot, locate the file, and restore it. For more information about RHSP, see “Implementing Riverbed Host Tools for snapshot support” on page 103.

When backups are taken at the branch using a backup application such as Symantec® NetBackup™ or IBM Tivoli® Storage Manager, you access and restore files directly from the backup server. We recommend that you restore the files to a different location in case you need to resort to the current files.

To recover individual files from a storage array snapshot of a export containing virtual disk (VMDK) files, present the snapshot to a VMware ESX Server, attach the VMDK to an existing VM running the same operating system (or an operating system that reads the file system used inside the VMDKs in question). You can then browse the file system to retrieve the files stored inside the VM.

To recover individual files from a storage array snapshot of an export containing individual files, present the snapshot to a server running the same operating system (or an operating system that reads the file system used on the export). You can then browse the file system to retrieve the files.

You can back up snapshots taken at the data center with a backup application or through Network Data Management Protocol (NDMP) dumps. In this case, file recovery remains unchanged from the existing workflow. Use the backup application to restore the file. You can send the file to the branch office location.

Alternatively, you can take the export offline from the branch office and inject the file directly into the export at the data center. However, Riverbed does not recommend this procedure because it requires taking the entire export down for the duration of the procedure.