Concepts You Should Know Before You Start
The IRM documentation uses the following concepts:
|
IRM CommCell |
Based on Microsoft Windows platform along with Microsoft’s SQL Server Express, the IRM CommCell retains all job management functionality, metadata, scheduling and reporting under a single console. This IRM CommCell composed of two standard components, the CommServe application and the MediaAgent. Together these two components live in a operating domain know as a single CommCell. |
|
CommServe |
The CommServe is the master server managing the configuration and operations for the CommCell. It is implemented on a Windows host server and contains an embedded version of Microsoft SQL Express used as the top level database in IRM. One CommServe is used per CommCell and it must be available to run operations. Only job control and metadata flow through the CommServe. Indexing and snapshot management routines are executed through the MediaAgent configured with in the CommCell. |
|
CommServe Database |
CommServe Database is based on Microsoft SQL Express Edition containing all the history and usage of the CommServe. Information such as the job history, the settings for each of the clients, media type, etc. are all stored within the database and every piece of information that is extracted / saved / deleted gets recorded within the CommServe Database. |
|
CommCell Console |
It is the console which embeds all the management feature and functions for the CommCell environment under a single pane. The console is java based and can be run as a local console instance or it can be accessed from anywhere through browser. All policies, operations, schedules, alerting and reporting are consolidated in this console and presented to users based on the security rights and roles they are authorized. |
|
MediaAgent |
The MediaAgent serves as a data mover and indexing resource in a data movement workflow in the data management environment. This component is used in various roles in the snapshot creation/mounting operations and the cataloging of content relevant to the client. The MediaAgent will also serve as the media library manager for the disk library to host index data. Those indexes are written in the Archive file format; those data sets are not available for direct mounting/use rather you would initiate a restore process to produce a native recovery copy of the data for use. |
|
IRM Clients |
Clients are the servers / systems leverage snapshot integration with the production storage arrays in IRM. A base File System iDataAgent will be installed on each of the servers to provide the core communication with the CommServe. From there depending on the information or data you wish to protect, you may load additional iDataAgents for application integration or VMware integration. These agents provide the proper level of integration at either File System, Database, Exchange, SQL, or VMware guest point of view to ensure that the correct data is protected at the right level. These agents will also ensure VSS writers are properly called to ensure the data in the snapshot at the point-in-time is consistent, provide the ability to call “ESEUtil” commands for Exchange Database consistency checking, and ensure VMware calls the appropriate software quiescing mechanisms for creating consistent VMs. |
|
Storage Policy |
Storage policy controls where the data is stored and how long the retention duration of the snapshot will be. Inside a Storage Policy are copies. These copies define retention for the selected storage devices in the IRM environment. There are only two copies of interest within IRM. The Primary Snapshot Copy and the Primary copy. The Primary Snapshot copy simply defines the retention of the snapshots that are taken, and the MediaAgent that will be cataloging the snapshot. The Primary Copy defines where the cataloged indexes are stored. |
|
Job Manager |
Displays all information pertaining to a particular running job – data protection / recovery / Auxiliary copy, settings, and media usages. From within the Job Manager, snapshot jobs may be started, suspended, resumed and killed. |
|
Backup Set |
A sub container found within each of these agents is a backup set. The backup set is the overall container of the client. The easiest way to understand a backup sets is to link it to context of the system that is being snapped in the environment. The basic physical system storage environment is the backup set for the file system iDataAgent, while the Exchange Information Store or SQL instance is the backup set for these two database agents. In a Virtual Context, an overall vCenter is the backup set as it contains many ESX server housing and managing the virtual machines. |
|
Subclient |
Subclients are the smallest subset of a client. It may be a single folder, a single database, a single Virtual machine or it may be a single LUN or a drive letter from a Windows host perspective (regardless of how many LUNs are meta-LUN'ed to provide 1 large LUN pool). Subclients are the definition inside of backup sets that are linked to Storage Policies which will define retention and location of the snapshot data. |
|
Index / Collect Files |
Collect Files are smaller text files that will capture information on what are on each of the clone / snapshots during an IntelliSnap job. When the snapshot is mounted to be cataloged, the original information residing on the snapshots are indexed by the collect files stored under the job result directory under each of the IRM clients. Once the cataloging has been completed, the information will be sent directly to the MediaAgent responsible for keeping that information longer term within indexes. These indexes will live on the MediaAgent for the life of the retention of the snapshot either on the local MediaAgent index cache, or as a part of the disk library defined to protect the indexes and the CommCell database backup. |