Commvault Certified Professional cheat sheet

The CommServe is the central Microsoft SQL Server–backed database and control service; it holds configuration, job metadata, and security policy but never moves backup data itself.

MediaAgents perform data movement to and from storage; a MediaAgent can be shared by many clients and can front disk, tape, or cloud libraries simultaneously.

The CommCell Console is the Java-based administration GUI; Command Center is the browser-based interface; both read and write the same CommServe database.

Clients host the File System iDataAgent or application agents; a client can hold multiple agents, and each agent holds one or more subclients that define what data is protected.

A subclient is the smallest protectable unit and determines content path, storage policy association, schedule, and backup options; a default subclient exists on every agent.

Index Cache on the MediaAgent stores the metadata catalog used during browse and restore; losing it forces a catalog rescan from media rather than data loss.

Job Controller service on the CommServe orchestrates job scheduling and dispatch; the CVD (Commvault Database) service manages the SQL database, and GxCVD handles CommCell communication.

A Storage Policy maps subclient data to one or more copies; each copy targets a library (disk, tape, or cloud) through a MediaAgent, and data is retained per copy.

Firewall-friendly topology requires inbound/outbound rules for CommServe-to-MediaAgent and MediaAgent-to-client ports; tunneling can reduce the number of open ports.

A storage policy contains at least one primary copy; additional copies (secondary, tertiary) are populated by auxiliary copy or synchronous copy operations.

Retention is defined on the copy, not the storage policy, and applies to the last protected full backup plus its dependent incremental and differential backups.

Deduplication can be performed at the MediaAgent (target-side) or at the client (source-side); source-side reduces network traffic, target-side reduces client CPU load.

The Deduplication Database (DDB) holds signature and block references; a partitioned DDB spreads signatures across MediaAgents and must be sized for growth.

Auxiliary copy jobs copy data between copies in a storage policy; they can run on a schedule or on demand and can be throttled to limit MediaAgent and network load.

Synthetic full backups combine a previous full with subsequent incrementals into a new full without reading the client, reducing backup windows.

Sealed and unsealed media: disk libraries use mount paths and extents; tape libraries use media pools and scratch pools, and retention drives when media is recycled.

Auxiliary copy supports deduplication-aware copying so only unique blocks are transferred to the destination copy, preserving deduplication ratios.

Storage policy copy precedence determines which copy is read for restores; setting a copy as read-only or offline shifts restore traffic to another copy.

File System iDataAgent supports full, incremental, differential, and synthetic full backups; incremental compares against the last backup, differential against the last full.

For SQL Server, the agent supports full, differential, transaction log, and copy-only backups; log backups require the database recovery model to be Full or Bulk-Logged.

Oracle agent uses RMAN integration; the agent can run full, incremental, and archive log backups, and restore supports point-in-time recovery to a specified SCN or time.

Exchange protection supports mailbox-level and database-level backups; granular recovery of individual mail items is performed from the mailbox or database backup without a full restore.

Application-aware backups use pre/post scripts or agent quiescing to guarantee consistent snapshots; VSS is used for Windows volume and application consistency.

Subclient content filters include include and exclude paths with wildcards; exclusions are evaluated before inclusions in some agent versions, so ordering matters.

Restore in place returns data to original paths; out-of-place restore targets an alternate client or path and requires the destination client to be registered.

Backup job options include deduplication, encryption, compression, and network throttling; these are set at the subclient or storage policy level and inherited unless overridden.

The Virtual Server Agent (VSA) protects VMware, Hyper-V, and Nutanix; it uses a proxy MediaAgent to read VM disk data and can offload processing to a dedicated proxy.

VMware backups use Changed Block Tracking (CBT) for incrementals; CBT must be enabled on the VM and reset if the change ID becomes invalid.

Transport modes for VMware include hot-add, SAN, NBD, and NBDSSL; hot-add mounts the disk to the proxy, SAN reads directly from the datastore, NBD uses the network.

Application-consistent VM backups use VSS or pre-freeze/post-thaw scripts inside the guest; crash-consistent backups capture the disk state without guest quiescing.

IntelliSnap uses array-based snapshots (e.g., NetApp, Pure, Dell) to create near-instant copies, with the snapshot engine configured per array and per subclient.

Cloud workloads: Amazon S3 and Azure Blob use a cloud library and a MediaAgent with internet or ExpressRoute connectivity; AWS EC2 and Azure VM protection uses the VSA.

Live Recovery and Live Browse let administrators mount a VM backup and browse or boot it without a full restore, using a temporary datastore or NFS export.

Guest file restore from a VM backup requires the index from the backup; if indexing was disabled, only full VM restore is possible.

CommCell security uses users, user groups, and roles; a role is a named set of permissions, and security associations bind roles to entities such as clients or storage policies.

Role-based access: the CommServe administrator has full rights; a tenant administrator is scoped to a company and its clients; an end user can restore only their own data.

Authentication options include Commvault-native, Active Directory, LDAP, and SAML/SSO; multi-factor authentication can be enforced for console and web logins.

Data encryption: backup data can be encrypted in transit (SSL/TLS) and at rest (software encryption with a passphrase or KMS/HSM-backed keys).

Compliance features include legal hold, retention lock (WORM), and audit trails; retention lock prevents deletion of protected data before the lock period expires.

Audit Trail logs administrative actions and job events; it is stored in the CommServe database and can be exported for compliance review.

Access control on subclients and storage policies is granted through security associations; a user without an association cannot see or restore that data.

Tenant (company) isolation separates data, users, and storage for multi-tenant deployments; a tenant admin cannot view other tenants' clients or jobs.

Job states include Pending, Running, Waiting, Completed, Failed, Killed, and Interrupted; a Waiting state often indicates a resource conflict such as a busy drive or MediaAgent.

Common failure causes: media offline or full, client offline, network timeout, insufficient disk space on the index cache or DDB, and credentials or firewall issues.

The Job Details and Job Logs views show phase-level errors; the Event Viewer and CommServe logs (CVD.log, GxCVD.log) capture service-level diagnostics.

Log files on MediaAgents and clients are enabled per component and can be collected with the Log Files utility or the Support Information collection.

Alerts and notifications can be configured for job failures, media errors, and threshold breaches; alerts are delivered via email, SNMP, or the console.

Reports include backup job summary, storage usage, client backup status, and SLA reports; reports are generated from the CommServe database and can be scheduled.

Health and performance monitoring uses the CommCell Console dashboard and the Metrics Reporting Server for historical trend data.

SLA-based monitoring compares completed backups against defined objectives; missed SLAs appear in the SLA report and can trigger alerts.

Upgrade order: upgrade the CommServe first, then MediaAgents, then clients; the CommServe must be at a version equal to or higher than its MediaAgents.

The CommServe upgrade uses the installation package with a database backup taken beforehand; the SQL database is upgraded in place and cannot be rolled back without the backup.

Client and MediaAgent upgrades can be pushed from the CommCell Console using the Software Installation or Upgrade option, in batches to limit impact.

Disaster recovery: a CommServe DR backup captures the CommServe database and configuration; it is scheduled and stored to a configured DR location.

Restoring a CommServe requires reinstalling the CommServe software, then restoring the DR backup during or after installation, then starting services.

MediaAgent DR requires reinstalling the MediaAgent and re-registering it to the CommServe; the index cache can be rebuilt by rescanning the media.

Maintenance tasks include DDB verification and compaction, index cache cleanup, media recycling, and pruning of old jobs and logs.

A DR plan should document the CommServe DR backup location, credentials, MediaAgent rebuild steps, and the order of service restoration.

The Commvault REST API is accessed over HTTPS at /commandcenter/api or /webconsole/api; authentication returns a token used in the Authtoken header for subsequent calls.

Common REST endpoints cover clients, subclients, storage policies, jobs, and events; jobs can be triggered, monitored, and queried through these endpoints.

The CommCell Console supports workflows and schedules; a workflow can chain tasks such as backup, auxiliary copy, and notification with conditional logic.

Command Line Interface (CLI) tools such as qoperation and qlist allow scripted job control and status queries on the CommServe and MediaAgents.

Event-driven automation uses alerts and workflows to react to job failures, media events, or threshold breaches without manual intervention.

PowerShell and Python SDKs wrap the REST API; they simplify authentication, pagination, and object creation for integration with orchestration tools.

Webhooks and third-party integrations (e.g., ServiceNow, ticketing) can be triggered from workflows or alerts to create incidents automatically.

Automation should use dedicated service accounts with least-privilege roles rather than administrator credentials to limit blast radius.