Robbie Cannings

CommVault Simpana IntelliSnap - DFM Dataset Naming conventions

Robbie Cannings -

Intellisnap delivers some superb integration between CommVault and NetApp, however there is still a litte bit which can cause operational confusion. One of these is Dataset naming. The basic workflow is that

  • A Simpana subclient is created with the IntelliSnap feature enabled
  • When the first backup job is executed, Simpana instructs DFM to establish a relationship between the primary data and the snapvault destination
  • A DFM Dataset is created with the appropriate details.

The Dataset name looks something like this:
CC-commserve01_SS-6840_SC-512

CC = CommCell
SS = Storage Policy
SC = Subclient

CommCell

The CommCell is quite simply the hostname of the commserve

Storage Policy

This is the primary key for the storage policy. You need to go into the CommCell database (e.g. via MS SQL Studio) and dump the SP table to translate this to a conventional SP name (e.g. SP_Silver_Snap = 6840 ; SP_Bronze_Snap = 13233)

Subclient

The “appid” field in the subclient DB table represents the Subclient. Again, export the table from the CommCell database to translate this.

  • Note: this table will also show whether there are any active schedules, and you can look at the most recent jobs, to determine if it is safe to delete a duplicate dataset related to this subclient.

Cleanup of duplicates etc

Using this simple (ish) conversion, you can safely determine whether a dataset is actively referenced by CommVault or whether it can be safely destroyed. There’s a dependency on access to the CommServe database, so the CommVault DBA may need to provide this info (or configure a read only database role to allow the appropriate people to access this information)