"Reserved copy space"

[Josh26]

Hey guys,

I have a number of 2TB LUNs participating in RC groups. Each of them has a "reserved copy space" of > 50%, leading to several "reserved" terabytes of storage.

This may have been necessary when first setup and a single sync involved multiple terabytes of backlogs, but we are currently running on 15 minute sync cycles and I struggle with the idea that that much copy space is generated each cycle.

Is there a way to reduce this sizing? I don't intend to go and allocate that space anywhere but I'd like to reduce the used capacity % down and clear more breathing room.

[Schmoog]

Hey guys,

I have a number of 2TB LUNs participating in RC groups. Each of them has a "reserved copy space" of > 50%, leading to several "reserved" terabytes of storage.

This may have been necessary when first setup and a single sync involved multiple terabytes of backlogs, but we are currently running on 15 minute sync cycles and I struggle with the idea that that much copy space is generated each cycle.

Is there a way to reduce this sizing? I don't intend to go and allocate that space anywhere but I'd like to reduce the used capacity % down and clear more breathing room.

Sounds like you may have some stray snaps taking up space...

Can you verify that remote copy is running correctly?

If you click the little plus by the vv in the MC, do you have snaps besides the rcopy snap that remote copy uses?

[Davidkn]

Is it not just a compact on the cpg required to free up the space again as it's just reserved, not necessarily being used?

[RitonLaBevue]

Did you ever try to apply freespace CLI command on these VVs ?

[Josh26]

Hi,

Many thanks for the assistance.


No, I hadn't tried "freespace", I wasn't familiar with this command. The only reference to it I can find is here:

http://h20566.www2.hp.com/portal/site/h ... .199480143

Accordingly - I'm unsure if I want to run this.

Regarding the snapshots, all of the RC luns have snapshot entitled "SRM_TARGETBK_RO_X" and "SRM_RECOVER_RO_X" for some a number x.
Edit: In addition to an rcopy.xx.xx snap.

It's obvious these are related to Site Recovery Manager - but that leaves me unsure if it's safe to remove them or tune the size in any way.

[Schmoog]

Interesting. I use srm as well, but I do not have any srm snaps. Is it possible that you have done a recover or test recover in srm and it didn't clean up the snaps it used?

Maybe you can send a screenshot? Are the srm snaps exported?

[Davidkn]

Yeah, sounds like you haven't either run a cleanup or ran a force cleanup and y need to manually remove the snaps theta didn't get removed.

[Josh26]

Hi,

I've attached a screenshot.

It does sound like your suggestion is correct - these snapshots date back quite some time. Can you advise on the appropriate cleanup process?

I've hunted around SRM but don't see anything unrelated to performing another failover.

Edit: And because you cannot see it in that screenshot, no, the snaps are not exported.

[Josh26]

Just to add to this, I've looked at the "force cleanup" process here:

http://pubs.vmware.com/srm-55/index.jsp ... B6419.html

Unfortunately the cleanup button is greyed out, I "think" this is because our SRM plan was deleted and recreated (and a "test" has not yet been done).

I'm leaning towards simply deleting the snapshot - it'd be great to get a confirmation that I'm on the right track (and the safest way to go it) before doing so.

And another edit: This screenshot is from the "Recovery" site of the SRM configuration. The other end has the same exact snapshots, plus the remote copy snap.

[Schmoog]

Josh,

Since the snaps are not exported, and your srm recovery plan has been deleted, if it were me I would blow out all the snaps except the rcopy snap of course without too much hesitation.

If it's not exported, then it's pretty safe to say it's not being used by anything (except for the rcopy snap which again is a different issue)