Commvault Certified Professional: CommCell Architecture and Core Components

Domain 1 - CommCell Architecture and Core Components

This domain tests whether you can map a protection requirement onto the correct CommCell object and place each service where it belongs. Questions typically probe the CommServe database, the MediaAgent data path and index cache, and the client → agent → instance → backup set → subclient hierarchy.

Core rules

• The CommServe is the single control point. It hosts the CommCell database (SQL Server) and the Job Manager, schedules and tracks jobs, stores policies and security - but it does not move backup data.
• MediaAgents move the bytes. Each MediaAgent owns its index cache and, where deduplication is used, the deduplication database it writes to. A job may be read by one MediaAgent and written by another.
• The subclient is the smallest unit you can protect, schedule and restore. Content, filters, storage policy and schedule are subclient properties, not client properties.
• The CommCell Console is the full administrative interface; Command Center is the web console used for delegated, day-to-day operations.
• Index data lets users browse and restore without rescanning media. It can be rebuilt from the backup data, so a lost index cache is a recovery-time problem, not a data-loss problem.
• Client groups, storage policies and subclient associations are what connect a machine to a data path; nothing is protected until a subclient has content and a storage policy.

Worked example

A file server has four volumes, and the business wants 90-day retention on home directories but 30 days on scratch data. Create one client, one file system agent and instance, one backup set, then two subclients whose content is the relevant volume paths. Point each subclient at a storage policy copy with matching retention. Put the index cache on the MediaAgent that writes the stream, sized from the file count and index growth rate, and confirm the MediaAgent is reachable on the data network from the client. If deduplication is required, ensure both subclients target the same dedupe database so blocks are shared.

Traps that cost marks

• Assuming the CommServe is in the data path and sizing it for throughput. It is not.
• Believing there is one dedupe database per storage policy. The dedupe database belongs to a MediaAgent and can be shared by several policies.
• Creating one subclient per server "to keep it simple", which forces a single schedule, retention and filter set onto all volumes.
• Confusing a backup set with a storage policy: the backup set groups subclients, the policy defines where and how long data is kept.