Can you break apart existing remote copy groups?

[jbguy]

In an effort to break up my remote copy group of 4 VVs I would like to create 2 sets of 2. This will help in not having to wait for all 4 to finish before I can make changes, throttle speed, etc. Will I need to do a full resync or will it use whats already at the destination 3PAR?

My guess is it will reuse it but wanted to make sure before I did anything and forced a full resync.

Thanks all.

[MammaGutt]

I've never played with periodic sync (which seems to be your flavour), but you have a -keepsnap option on dismissrcopyvv which should ensure that you only need to resync changes and not the entire vv.

[robertcorey]

I've never played.The ability to move a virtual volume between remote copy groups without the need for a full synchronization was added. This is helpful in certain scenarios where you'd like to move the vv to another copy group without triggering a full synchronization.You have a keepsnap option on dismissr copyvv which should ensure that you only need to resync changes and not the entire vv.
Creating a very successful essay depends highly on prior preparation for the essay writing process. This is one of the main secrets, which if applied well, you can come up with a very quality academic paper. For that you should be ensuring that you have a clear outline to follow when you start writing your essay. To maintain your essay perfect and quality you must be consider only on creating notes prior to the actual writing process.Visit Custom essay writing service

[RitonLaBevue]

As MammaGutt said, you must use "-keepsnap" option with the dismissrcopyvv.
Then it creates a virtual copy name sv.* for each dismissed vv.
Then create a new remote copy group, and use "admitrcopyvv vvname:virtualcopyname rcopygroup targetarray:targetvvname.

[Jim Mc]

Retracted this comment because it's irrelevant.

[jbguy]

Thanks for all the input everyone. I did try and succeed at removing a member of a remote copy group and keeping the snap. I was able to re-add it and use the saved snap. It didnt fix the issue I hoped it would though which was the reserved copy space of the volume not going down after initial sync. Right now I have almost 13tb tied up on this volume that wont release. I think I need to contact HP as all attempts and different strategies have failed. I may just remove it from the RC group and have it do a full sync again. Not preferable but may be my only option.

[Jim Mc]

If you delete all the unneeded snaps associated with the volume, you need to then wait 24 hours for the garbage collection to clear down the reserve copy space.

Once the reserve copy space is reduced it'll release the space back to the CPG level. If you then want to see the space released back to the PDs from the CPG you need to run a compactcpg.

[jbguy]

If you delete all the unneeded snaps associated with the volume, you need to then wait 24 hours for the garbage collection to clear down the reserve copy space.

Once the reserve copy space is reduced it'll release the space back to the CPG level. If you then want to see the space released back to the PDs from the CPG you need to run a compactcpg.

Thanks for the tips. In a remote copy scenario how do I know which ones I need and which I dont?

[RitonLaBevue]

If the used copy space of a volume is 0 then you can use "freespace -f <vvname>" to free the reserved copy space.

About the keepsnap option, once the vv is synced you will need to remove manually the sv.* victual copy.

[MammaGutt]

Since periodic replication always keep a snap active, freespace doesn't help.