Backup architecture on NetApp FAS systems
In this article, I will look at how the SnapProtect architecture implements the “NetApp backup paradigm” using advanced technologies and the benefits of storage systems of the FAS series. SnapProtect (SP) software is designed to manage the life cycle of backups, archiving and restoring data for the entire infrastructure located on the NetApp FAS storage system . SP provides connectivity with applications, consistency when backing up a backup, managing replication / archiving between repositories, cataloging, restoring data if necessary, checking backups, and other functions. FAS is a very versatile system that can be used for tasks like “primary” storage , “spare” ( DR ), and for data archiving.
The SnapProtect complex consists of the following main components:
')
There are such iDA agents:
Consistency, as mentioned earlier, is performed by the iDA agent on the host, so before removing the hardware-assistant SnapShot on the storage side, the agent “prepares” the application. This method of backup can be performed many times, right among the working day, since clients connected to such applications will not even notice these processes.
Replication of (consistent) snapshots between storage can be performed using SnapMirror or SnapVault.
Data transfer from the main or backup system to the tape library is performed via media agent for SAN and NAS data. Also, for the NAS, you can fill data directly from the NetApp storage to the tape library using the NDMP and SMtape protocol, unfortunately, in this case data cataloging is not supported.
Catologization is performed as a post-process by priaplivaniya cloned (FlexClone technology) snapshots from the storage NetApp.
Data recovery can be performed from a remote repository, local or from a tape library.
There are several ways (you can even say ways) to recover, depending on the type of data, the type of recovery and the location of this data.
So, to restore the entire Volume or qtree from the snapshot on the local storage, the technology of instant recovery by means of the storage from the snapshot can be used - SnapRestore. With a similar recovery but from a remote system, you will need to perform "reverse replication" using SnapMirror or SnapVault technology. It is possible to replicate not only the latest data, but also one of the snapshots located on a remote repository.
If there is a need for “granular recovery”, the internal logic looks like cloning a snapshot of a remote or main system and connecting it to a media agent, then the necessary objects are transferred from the media agent to the required host. Recovery from a tape library occurs in a similar way - through a media agent to the host.
Technologies required in storage:
Thus, summing up, we can say that the main site must necessarily contain the technologies FlexClone, SnapRestore, one of the replication licenses (SnapVault / SnapMirror) and SnapProtect itself.
At the backup storage, FlexClone is therefore required if cataloging will be performed there. If the backup / restore scheme requires the ability to quickly restore the Volume from a snapshot on a remote storage, then such storage requires SnapRestore technology. Since we replicate data from the main system to the remote one, support of the replication technology (SnapVault / SnapMirror) is also needed on the remote system. Everything else needs the support of SnapProtect itself.
As a result, NetApp strictly regulates, for the “two-site model,” additional licenses for primary and backup storage systems for the SnapProtect architecture deployment:
Granular restoration.
The granularity of recovery refers to the ability to recover not a whole LUN / Volume with data, but individual objects or files residing on a LUN . For example, for a virtual infrastructure, such an object could be a virtual machine, a virtual machine file, a vDisk, or individual files inside a virtual machine. For databases, such an object can be a separate instance of the database. For Exchange, it can be a separate mailbox or a separate letter, etc.
SAN + Granular backup and restore
In the case of using SnapProtect architecture with a SAN network, application data that requires granular restoration (such as Exchange, Oracle, MS SQL, and others) should be placed on a separate, dedicated LUN . In the case of server virtualization with such applications, the same rule applies: it is necessary to place data from these applications on a separate dedicated RDM disk. The LUNs themselves on the storage system side must each be in a separate Volume. For example, in the case of virtualization with the Oracle database and using the SAN network, it is necessary to allocate for each data type for this database a separate LUN connected in the form of RDM , exactly according to the same rules as if instead of SnapProtect we used SnapManager. Those. SnapProtect's drive partitioning and placement logic will be the same as for SnapManager, the same rules apply here. After all, the technology of consistent removal of hardware-assistant snapshots in both cases are similar, if not to say identical.
You can see this example in more detail in my article “SnapManager for Oracle & SAN network” on Habré.
I ask to send messages on errors in the text to the LAN .
Notes and additions on the contrary please in the comments
The SnapProtect complex consists of the following main components:
- Server with SnapProtect Management Server (CommServe license), clustering is used for fault tolerance (at the application level + database clustering)
- Servers with installed MediaAgents.
- IDataAgent (iDA) agents. Installed on hosts for integration with the OS , file systems, applications and other components of the host OS .
- SP communicates with the NetApp repository through the Oncommand Unified Manager.
')
There are such iDA agents:
- VSA - For VMWare and Hyper-V
- for Oracle under Windows / Unix / Linux (including with RAC )
- for Exchange (including DAG )
- for MS SQL
- for SnarePoint
- Qsnap Driver for Win / Unix file systems
- NAS NDMP iDA
- DB2 Unix / Linux
- Lotus Domino on Windows
- Active Directory iDA
Consistency, as mentioned earlier, is performed by the iDA agent on the host, so before removing the hardware-assistant SnapShot on the storage side, the agent “prepares” the application. This method of backup can be performed many times, right among the working day, since clients connected to such applications will not even notice these processes.
Replication of (consistent) snapshots between storage can be performed using SnapMirror or SnapVault.
Data transfer from the main or backup system to the tape library is performed via media agent for SAN and NAS data. Also, for the NAS, you can fill data directly from the NetApp storage to the tape library using the NDMP and SMtape protocol, unfortunately, in this case data cataloging is not supported.
Catologization is performed as a post-process by priaplivaniya cloned (FlexClone technology) snapshots from the storage NetApp.
Data recovery can be performed from a remote repository, local or from a tape library.
There are several ways (you can even say ways) to recover, depending on the type of data, the type of recovery and the location of this data.
So, to restore the entire Volume or qtree from the snapshot on the local storage, the technology of instant recovery by means of the storage from the snapshot can be used - SnapRestore. With a similar recovery but from a remote system, you will need to perform "reverse replication" using SnapMirror or SnapVault technology. It is possible to replicate not only the latest data, but also one of the snapshots located on a remote repository.
If there is a need for “granular recovery”, the internal logic looks like cloning a snapshot of a remote or main system and connecting it to a media agent, then the necessary objects are transferred from the media agent to the required host. Recovery from a tape library occurs in a similar way - through a media agent to the host.
Technologies required in storage:
Thus, summing up, we can say that the main site must necessarily contain the technologies FlexClone, SnapRestore, one of the replication licenses (SnapVault / SnapMirror) and SnapProtect itself.
At the backup storage, FlexClone is therefore required if cataloging will be performed there. If the backup / restore scheme requires the ability to quickly restore the Volume from a snapshot on a remote storage, then such storage requires SnapRestore technology. Since we replicate data from the main system to the remote one, support of the replication technology (SnapVault / SnapMirror) is also needed on the remote system. Everything else needs the support of SnapProtect itself.
As a result, NetApp strictly regulates, for the “two-site model,” additional licenses for primary and backup storage systems for the SnapProtect architecture deployment:
Granular restoration.
The granularity of recovery refers to the ability to recover not a whole LUN / Volume with data, but individual objects or files residing on a LUN . For example, for a virtual infrastructure, such an object could be a virtual machine, a virtual machine file, a vDisk, or individual files inside a virtual machine. For databases, such an object can be a separate instance of the database. For Exchange, it can be a separate mailbox or a separate letter, etc.
SAN + Granular backup and restore
In the case of using SnapProtect architecture with a SAN network, application data that requires granular restoration (such as Exchange, Oracle, MS SQL, and others) should be placed on a separate, dedicated LUN . In the case of server virtualization with such applications, the same rule applies: it is necessary to place data from these applications on a separate dedicated RDM disk. The LUNs themselves on the storage system side must each be in a separate Volume. For example, in the case of virtualization with the Oracle database and using the SAN network, it is necessary to allocate for each data type for this database a separate LUN connected in the form of RDM , exactly according to the same rules as if instead of SnapProtect we used SnapManager. Those. SnapProtect's drive partitioning and placement logic will be the same as for SnapManager, the same rules apply here. After all, the technology of consistent removal of hardware-assistant snapshots in both cases are similar, if not to say identical.
You can see this example in more detail in my article “SnapManager for Oracle & SAN network” on Habré.
I ask to send messages on errors in the text to the LAN .
Notes and additions on the contrary please in the comments
Source: https://habr.com/ru/post/244677/
All Articles