SnapProtect - SnapProtect for Open Systems - Getting Started – NetApp

SnapProtect for Open Systems is a full volume block level incremental replication feature. It replicates heterogeneous data from source partitions and volumes from Unix and Windows clients to a NetApp 7-mode destination filer as a single LUN with a single partition onto a SnapVault Copy. The source volumes could be carved out of disks that are locally attached to the client or from disks that are externally attached to the client from non-NetApp hardware arrays. It uses NetApp’s OnCommand Unified Manager to provision the destination volumes to which data is replicated. Data is replicated as GPT LUN on Windows. On Unix, LUN has the same format as the source volume LUN.

Running SnapProtect for Open Systems jobs from the replication workflow enables the use of a single destination NetApp volume as a fan-in destination for many clients under a single DataSet context. It allows a group of clients to be controlled by a single job management context (providing a many-to-one control). This group now defines the operations job unit which triggers the recovery point snapshots on the SnapVault destination.

Using a consolidated dataset with SnapVault automatically pull in any efficiencies that NetApp deduplication can achieve across the collection of the replicated disk images that are maintained with SnapProtect for Open Systems.

The following illustration describes the process involved in SnapProtect backup:

How does SnapProtect for Open Systems work

The SnapProtect for Open Systems replication will happen in the context of SnapProtect backup. To carry out the replication transfer, you should run or schedule the replication workflow from the storage policy to which all the clients that need to be protected are associated. The workflow will in turn start of individual SnapProtect backup jobs for each of the associated subclients. Each SnapProtect backup job for a subclient does the following:

  • Creates a software snapshot of the source data using the native Snap engine such as VSS or QSnap/LVM.
  • The volume is added to the OnCommand Unified Manager dataset that corresponds to the primary snap copy of storage policy to which the subclient is associated.
  • The OnCommand Unified Manager carries out any provisioning tasks and requests the destination filer to connect back to the client SnapProtect for Open SystemsTransfer/SnapProtect for Open SystemsTest process.
  • If the volume has never been protected before, then the SnapProtect for Open Systems agent will perform a baseline transfer, i.e., transfer all blocks for the volume to the destination filer.
  • If the volume has been protected before, then the SnapProtect for Open Systems agent will figure out all the blocks that have changed for the volume since the last backup, using SHA-1 checksum mechanism and a checksum database and transfer only the changed blocks to the destination file server. For a given volume, all backups, except the first, are incremental.

When the SnapProtect for Open Systems transfer to all the associated subclients is complete, a destination snapshot is taken on the destination vault copy and this snap is registered as the primary copy of data for that application against the primary snap copy. The software snap that was created at the start of the SnapProtect backup job is deleted once the SnapProtect for Open Systems transfer for source snapshot is successful.

The following illustration depicts the modules:

Link-1: the backup processes interact with DFMserver using dfm sdk to add host and volumes to the OnCommand Unified Manager dataset and to run backup.

Link-2: DFMserver communicates to NDMPListener to get and validate host details.

Link-3: DFMserver creates /updates relationship with secondary filer and instruct filer to get the data from LREPListener to protect the dataset.

Link-4: When Secondary Filer gets a backup request, it connects to the source host on port 10566 to get the replication data from the LREPListener.

The SnapProtect job type maybe full, differential. or incremental, but the SnapProtect for Open Systems transfer is always incremental, once a baseline for a volume is established.

Processes Specific to SnapProtect for Open Systems

Replication workflow – Central coordinating process which coordinates the backup processes for all the subclients of the replication workflow.

NDMPListener – Listens on port 10,000. The NDMPListener is required by the OnCommand Unified Manager server for host validation, and file system directory hierarchy discovery and validation. This thread runs on the source host in the context of CVD in a thread and will start with CVD startup.

LREPListener – Listens on port 10566. It runs on the source host is started on demand when the SnapProtect for Open Systems backup runs. This is the port through which data gets transferred to the destination filer. LREPListener continues to run even after the backup completes.

LREPCoordinator – Runs on the MediaAgent, associated with the storage policy on which the workflow is triggered. It is responsible for starting the on-demand OnCommand Unified Manager job, which will in turn trigger incremental updates from the source hosts to the destination filer for each of the source volumes involved in the SnapProtect for Open Systems backup job.

Mapping entities between SnapProtect and OnCommand Unified Manager

SnapProtect OnCommand Unified Manager Entity
Storage policy snap copy and subclients associated with the snap copy Dataset
Complete Source volume derived from subclient content Dataset member
Storage policy snap copy Storage Service