I’ve found a small quirk with RecoverPoint not registering LUN name changes using RecoverPoint 3.1 SP 1, though I noted the same issue in previous versions as well.
I like to keep my LUN named with a naming convention with usage description. I also do my best to not delete a LUN if there’s a chance I can reuse it in the near term. Removal of a LUN leaves unused tracks potentially between tracks used by other LUN, this becomes a greater concern when using MetaLUN. I’m just not a fan of having non-contiguous space on my disk and the process of a defrag can take a long time and puts a decent load on the disks with a performance impact.
All that said, I try to reuse my LUN requiring a rename upon reuse. Since most of the data is replicated via RecoverPoint most of the LUN have been previously configured. I’ve attempted to rename a LUN and immediately reuse and initialize replication again though the new LUN names were not picked up. Call it nothing short of anal retentive behavior but I don’t like seeing the wrong volumes names in the properties views. I finally found that the method of purging the apparent caching of LUN names is the remove from the SAN storage group (or whatever HDS, Netapp, etc calls them), preforming a rescan on storage in RecoverPoint then re-adding and continue on with business.
I wish a simple rescan of storage on RecoverPoint would update the names but it’s not the case.