How To Delete Orphan Replicated Volumes

[warkaj1]

So the process for deleting orphaned volumes that were once part of replication seems a bit ... scary.... to me.

The process as explained to me is this:

• Promote the volcoll on the downstream
• Go to each of the member volumes and then offline and delete them
• Once all the volumes are gone, you can delete the volcoll itself

This scares me because IF by the wild chance someone kicks off a rescan of datastores or HBAs during the period I'm promoting and deleting these volumes (I have 9 of them totaling 1.01 TB) then they're going to conflict with the volumes associated with the very important VM that is operating on those volumes. If those volumes or the VM get even a bit dinged up it's going to be painful in the office for me haha.

Anyone killed orphaned volumes from replications without incident? Just has me a bit shaky on doing this.

Thanks,

Andrew

[pfrisoli27]

Hello,

I would log a call into Support to clarify the process. There is a KB Article via the Support site titled "KB-000096 Orphaned Snapshots" but it does not speak to replica orphans. I hope this helps and I will work to gain additional clarity for you. Thanks

[bgrieve65]

Hey Andrew,

Are both arrays in the same data center and/or on the same iSCSI subnet? I ask because if the hosts don't have connectivity to the iSCSI subnet on the replica side, they would never see the replicas once the VolColl is promoted.

Outside of this, I agree with Paul that it wouldn't hurt to engage Support to ensure that there are no gotchas in your plan.

[warkaj1]

Different data centers, same campus, same subnet.

[foodandbikes · Accepted solution]

I've done this several times, all without issue. I had the same reservations you do.

Promoting the volcol does not grant iSCSI access to the volumes. The volumes may even remain offline if I recall correctly.

From memory:

1. promote volume collection. I think volumes remain offline, if not offline them. Then wait for a while before step 2. No sense in rushing this.

2. delete volumes

3. delete volcol

If by some chance a rescan was done of storage (assuming VMware) and it miraculously had access, VMware would see the same disk identifier and would not bring them online. They may appear in the list of datastores with _snapshot appended to the end.

[tmoore106]

When you promote the volume collection on the downstream array the volumes in that collection do become first class volumes and they do immediately go online. However, there is no access to the volumes via initiator group or chap. See attached. NOS 2.1.4, downstream array, promote volcollection, verify online, notice the access. So even if somebody rescind, the volume would not been seen.

[warkaj1]

Well, finally ended up doing it and deleting those replicated volumes. It's as advertised, no problems to report.

Process was simple:

• promote volCol
• edit volCol and remove volumes
• offline volumes
• delete volumes
• delete volCol

All done, reclaimed about 5% of my storage array by doing that.

S/F

[KSALinville]

Just some clarification to the above solution

At the command line:

Nimble OS $ volcoll --list

Nimble OS $ volcoll --promote volcoll_name

Nimble OS $ volcoll --list

In the NimbleOS GUI:

edit volCol and remove volumes

offline volumes

delete volumes

delete volCol

This worked great for what I needed.

Thanks!

- Kris