Introduction
Modern enterprises rely heavily on consistent, rapid, and application‑aware data protection capabilities to meet demanding RPO/RTO expectations. For customers running applications like Microsoft SQL Server, Oracle, InterSystems Iris, SAP-HANA on VMware with Dell PowerMax as the underlying storage, IBM Storage Defender Copy Data Management (CDM) offers an orchestrated, automated, and fully governed approach to snapshot creation, recovery, and lifecycle management.
This blog walks through a real‑world configuration, based on an IBM customer scenario, highlighting how CDM discovers VMware/SQL/database topology, orchestrates storage‑level snapshots on PowerMax, and automates end‑to‑end clone, restore, and cleanup workflows.
Goal of the blog:
- Help customers understand how CDM interacts with their environment and how resources are managed by CDM on Dell PowerMax storage, showcasing the exact resources CDM creates, along with their naming conventions.
- Brief overview of a SQL virtual database on VMware with Dell PowerMax, for CDM v2.2.28.1 and beyond.
Environment Overview
The environment in discussion consists of:
- MS SQL Server virtual machine hosted on VMware vSphere.
- MS SQL VM mapped to four VMware datastores.
- Dell PowerMax storage system providing backend volumes
- IBM Storage Defender CDM v2.2.28.1 or above deployed & configured to orchestrate snapshot and recovery workflows.
VMware Datastore Configuration
The SQL VM is mapped to four datastores, each backed by a corresponding volume on Dell PowerMax storage:
|
Sr No
|
Datastore Name
|
Associated Volume on Dell PowerMax storage
|
|
1
|
SQL-vir-DATA
|
00B37
|
|
2
|
SQL-vir-LOG
|
00B38
|
|
3
|
SQL-vir-OS
|
00B36
|
|
4
|
SQL-vir-SQL
|
00B39
|
Dell PowerMax Storage Group Configuration
Supported Example Configuration:
The environment in this scenario uses:
- 1 Parent Storage Group (SG): SQL-Standalone-VIR
- 4 Child Storage Groups:
SQL-SD-virtual_1, SQL-SD-virtual_2, SQL-SD-virtual_3, SQL-SD-virtual_4
All relevant volumes (00B36, 00B37, 00B38, 00B39) reside inside these SGs. CDM interacts with this hierarchy when orchestrating snapshots and clones.
Note:
CDM v2.2.28.1 and above recommends having non-database related volumes(eg. OS) outside of the parent SG. This helps isolating only database related volumes like data and log in the snapshot and thereby reducing number of volume clones when the snapshot is linked during restore.
Having said that, CDM continues to work even if non-database related volumes included in the parent SG.

Application‑Aware Snapshot Orchestration
CDM automatically discovers the SQL VM’s topology and identifies which datastores contain data/log files using database inventory, making them eligible for storage‑level snapshots.
Key Outcomes from CDM’s snapshot workflow:
For the environment in above scenario:
- CDM identifies SQL-vir-DATA and SQL-vir-LOG as datastores eligible for snapshot on storage, based on the database related disks like data and log associated to the SQL.
- CDM resolves these datastores to 00B37 and 00B38 volumes on storage respectively.
- CDM figures out SQL-Standalone-VIR as the parent SG for these 2 eligible volumes for snapshot on storage.
- CDM issues a single snapshot call to PowerMax for parent SG SQL-Standalone-VIR*
- CDM creates one consistent snapshot - Snap_1010_1002_9 on the storage.
*Note:
- This snapshot includes all volumes and child SG present in parent SG as CDM can only take Storage Group level snapshots.
- Dell PowerMax Unisphere does not allow CDM to use more granular APIs to operate at volume level.
Total count of resources created by CDM on storage – 1
· Parent SG Snapshot - Snap_1010_1002_9
Instant Database Clone Restore
When a restore is initiated, CDM uses the snapshot and clone capabilities to mount the copy of the database to the target host.
Key Outcomes from CDM’s Restore workflow
For the environment in above scenario:
- CDM identifies snapshot Snap_1010_1002_9 as the latest candidate for restore.
- CDM performs clone (SG link) operation for this snapshot and creates clone SG with name ECX_1011_1771496019209_00_00B38 on the storage. PowerMax internally creates associated child SGs that were part of the snapshot along with cloned volumes 00B57,00B58, 00B4D and 00B4E.
- CDM performs mapping operation (masking view creation) to the destination host (tpp-27HXYS3) for the relevant database associated child SG clones from the cloned SG ECX_1011_1771496019209_00_00B38.
Total count of resources created by CDM on storage: 11

Cloned parent SG – 1
- ECX_1011_1771496019209_00_00B38
Cloned child SGs – 4
- ECX_1011_1771496019209_00_00B38_1
- ECX_1011_1771496019209_00_00B38_2
- ECX_1011_1771496019209_00_00B38_3
- ECX_1011_1771496019209_00_00B38_4
Cloned volumes – 4
- 00B57, 00B58, 00B4D, 00B4E
Masking Views – 2
- ECX_1011_1771496019209_00_00B38_3_tpp-27HXYS3_MV
- ECX_1011_1771496019209_00_00B38_4_tpp-27HXYS3_MV
Automated Cleanup / Refresh
CDM ensures that the storage environment remains clean after restore or test operations.
CDM executes a structured teardown sequence:
- Issues cleanup call for the cloned snapshot.
- Resolves all cloned resources in dependency order, including:
- Masking views
- Child SGs
- Parent SG
- Cloned volumes
- Deletes resources in the correct hierarchy, ensuring:
- No orphaned SGs
- No stale volumes
- No leftover masking views
Total cloned resources remaining after cleanup: 0.
This ensures storage hygiene and minimizes administrative overhead.
What's new compared to CDM 2.2.28 and before?
As of CDM 2.2.28,
With reference to above environment scenario, CDM used to resolve all associated datastores to the VM and take individual snapshots for all the datastore-associated volumes to the SQL VM, basically not having any SQL database context awareness during snapshot operation. This used to result in 4 snapshots for above scenario versus only 1 consistent snapshot starting with CDM 2.2.28.1.

Below table helps compare the reduction in number of resources created on the storage during snapshot and recovery workflows with above environment as an example:
|
Resource Type
|
Count (CDM 2.2.28)
|
Count (CDM 2.2.28.1 & beyond)
|
|
Snapshots
|
4
|
1
|
|
Cloned Parent SG
|
2
|
1
|
|
Cloned Child SG
|
8
|
4
|
|
Masking Views
|
2
|
2
|
|
Total
|
16
|
8
|
Roughly 50% reduction in total number of resources created on the Dell PowerMax storage.
Conclusion
Ultimately, CDM’s optimised snapshot workflow not only simplifies SQL protection on VMware with Dell PowerMax but also enhances restore efficiency.
By understanding how CDM discovers resources, selects snapshots, creates clones, and performs cleanup, customers can architect their environments for maximum efficiency and alignment with best practices. This improved workflow demonstrates CDM’s continued commitment to delivering intelligent, application‑aware resilience for enterprise workloads.
~ Pranit Reke | Software Developer, CDM
Tags:
#IBMStorage, #IBMStorageDefenderSentinel, #IBMStorageDefenderCopyDataManagement, #DataResilience, #VMware #Dell #PowerMax #CDM #Sentinel #IndexEngine #VirtualMachine #VM #consistency #SQL