SnapProtect for Open Systems

In continuation of the topic about SnapProtect software: Backup architecture on NetApp FAS systems , I want to highlight the functionality of SnapProtect for Open Systems. Beginning with the release of SnapProtect 10.0 Service Pack 4, NetApp now supports backups from direct-attached and “third-party” repositories to Data ONTAP 7-Mode SnapVault systems.

SnapProtect for Open Systems, or shortly (SPOS), performs block incremental replication, supporting Windows, Linux and Solaris OSs , as well as applications such as Microsoft Exchange Server, Microsoft SQL Server, and Oracle Database.


SPOS operation diagram
')
The fundamental difference between this scheme and the standard NetApp approach to backups is that the snapshots are taken not at the Storage Assistant level (Hardware Assistant), but at the file system level (or file manager type LVM ) of the host OS itself.


To use the SPOS function, the following components must be installed on a Windows or UNIX source host:

• MediaAgent: On all hosts
• Windows: VSS software provider
• UNIX: Qsnap Driver or Linux LVM or Veritas VxvM
• SnapVault license on storage (where backup copies will be placed)

There are also several important points when introducing SPOS version 10.0 SP 4:

• 7-Mode Data ONTAP version 7.3.x and newer systems are supported.
• No SPOS backup support on Clustered ONTAP yet
• Supported only with OnCommand Unified Manager 5.2 ( currently there is no SPOS support in OCUM 6.x)
• DB2 DPF and MySQL applications are not supported on SPOS
• 7-Mode vFiler (MultiStore) is not supported as a recipient, except for vFiler0
• Raw partitions on UNIX are not supported.
• No support for clustered applications or clustered file systems
• Backup for Exchange Database Availability Groups (DAG) is not supported
• Oracle RAC and ASM are not supported.
• ZFS file system not supported (Oracle Linux / Soraris)

The process of performing such a backup looks like this:

• A software snapshot is created at the data source using a native engine, such as VSS or Qsnap / LVM
• The partition is added to OnCommand Unified Manager Dataset (corresponds to the system's primary section) to the storage policy and then the client from which the backup will be made is attached to it.
• OnCommand Unified Manager performs all backup scheduling operations and sends commands to the remote FAS system so that it connects to the data source and starts copying the data. Copying is performed according to the “Pool” tenology, i.e. it is not the client that pushes the data onto the backup system, but the backup system pulls in the data from the client.
• If a partition has not been previously saved, basic data transfer will be performed (i.e. - transfer of data blocks from source to destination)
• If a partition was previously saved, then only the modified data from the last transfer time will be transferred. Here, a cheksum mechanism based on SHA-1 and a chexum database are used to transfer so much changed data to the receiver. For each such partition, all backups (with the exception of the first) are incremental.
• When the transfer for all clients is completed, a Snapshot is run on the remote storage and this Snapshot is registered as the main copy of the data for the application, which corresponds to the snap copy on the main system. After that, the software that performed the Snapshot on the main system deletes the Snapshot upon completion of the task as soon as the data transfer is completed successfully.
• Data recovery by the “target” is performed directly, and file-by-file recovery occurs through the media agent. The cloned snapshot is connected to the media agent and the agent copies all the necessary data.

Comments on errors in the text and suggestions please send to the LAN .