SnapProtect for Open Systems

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

    «SnapProtect for Open Systems» or short (SPOS), executes a block incremental replication podderzhdivaya OS Windows, Linux and Solaris, as well as applications such as Microsoft Exchange Server, Microsoft SQL Server and Oracle Database.


    flow chart The main difference between this scheme and the standard NetApp backup approach, is that Snapshots are removed not at the level of the storage (Hardware Assistant), but at the level of the file system (or file manager such as LVM ) of the host OS itself.

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

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

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

    • 7-Mode Data ONTAP version 7.3.x and newer systems are supported.
    • No support for SPOS backups on Clustered ONTAP yet
    • Only supported with OnCommand Unified Manager 5.2 (no SPOS support in OCUM 6.x yet )
    • DB2 DPF and MySQL applications are not supported in SPOS
    • 7-Mode vFiler (MultiStore) is not supported as a receiver, except for vFiler0
    • Raw UNIX Partitions 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 not supported
    • ZFS file system not supported (Oracle Linux / Soraris)

    The process of performing such a backup looks like this:
    • Software Snapshot is created on the data source using a “native engine” such as VSS or Qsnap / LVM
    • The section is added to the OnCommand Unified Manager Dataset (corresponds to the system primaries section) to the storage policy and then the client from which the backup will be performed is attached to it.
    • OnCommand Unified Manager performs all backup planning 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 using the “Pool” tenology, ie it is not the client that pours data onto the backup system, but the backup system pulls the data from the client.
    • If the section was not previously backuped, basic data transfer will be performed (i.e. - transfer of data blocks from source to destination)
    • If the section was previously backed up, then only the changed data will be transferred from the time of the last transfer. Here the mechanism of a checker based on SHA-1 and a checker database is used to transfer so much changed data to the recipient. For each such partition, all backups (except the first) are incremental.
    • When the transfer for all clients is completed, Snapshot is executed 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 executed Snapshot on the main system deletes Snapshot at the end of the job, as soon as the data transfer is completed successfully.
    • Data recovery is carried out in full by direct, and file-by-file recovery occurs through a media agent. A cloned snapshot is connected to the media agent and the agent copies all the necessary data.

    Please send comments on errors in the text and suggestions to the PM .

    Also popular now: