SnapProtect - SnapProtect for Open Systems - Getting Started – NetApp
SnapProtect for Open Systems (SPOS) 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 can 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 OnCommand Unified Manager (OCUM) to provision the destination volumes to which data is replicated. Data is replicated as GPT LUN on Windows. On UNIX, the LUN has the same format of the source volume LUN.
Running SPOS 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 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 by SPOS.
The following illustration describes the process involved in SnapProtect backup:
How SnapProtect for Open Systems works
The SnapProtect for Open Systems replication happens in the context of SnapProtect backup. To carry out the replication transfer, run or schedule the replication workflow from the storage policy to which all the clients that need to be protected are associated. The workflow, in turn, starts off 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.
- Adds the volume to the OCUM dataset that corresponds to the primary snap copy of the storage policy to which the subclient is associated.
- OCUM carries out provisioning tasks and requests from 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 SPOS agent performs a baseline transfer, i.e., transfers all blocks for the volume to the destination filer.
- If the volume has been protected before, then the SPOS agent calculates all blocks that have changed for the volume since the last backup, using the SHA-1 checksum mechanism and a checksum database to 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 OCUMServer to add host and volumes to the OCUM dataset and to run backup.
Link-2: OCUMserver communicates to NDMPListener to get and validate host details.
Link-3: OCUMserver creates and updates the relationship between the 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 SPOS transfer is always incremental, once a baseline for a volume is established.
Processes Specific to SnapProtect for Open Systems
Replication workflow – Coordinates the backup processes for all subclients of the replication workflow.
NDMPListener – Listens on port 10000. The NDMPListener is required by the OCUM 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 starts on-demand when the SPOS 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 OCUM job, which, in turn, triggers incremental updates from the source hosts to the destination filer for each of the source volumes involved in the SPOS 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|