Timefinder/clone on a source device that is already R1

Yes.

I'd say "absolutely"

[Don't forget to add the -TGT switch when you add the target devices to the SRDF groups...]

Shouldn't I create a new group for the local TF/clone session instead of using the existing RDF1 group used for remote replication?

Both R1 and R2 can be the source of a TimeFinder/Clone session.
Don't forget to add the -TGT switch when you add the target devices to the SRDF groups...

You can choose. The good old way (put everything in a single DG) will work flawless and won't affect your replication. SRDF/A switches cycles regardless of what your host is doing.
A DG is simply a container, a cheap and easy way of telling the storage what devices you are trying to clone (and their corresponding targets, of course).

So your recommendation is to add the TGT devices to the existing RDF group and run symclone session commands against the local SRC and TGT devices?

Could this affect the SRDF/A replication if we plan to establish the local clone every 15 mins?

So then with all TF/clone and RDF devices in one group, could the symrdf commands (such as disable and establish) affect the TF sessions? Or conversely, could the symclone commands the affect the SRDF replication?

if RDF and TF commands run at the same time they might bump into each other just from symcli perspective, one might get error that symapi is locked or something like that. You can build some logic in your script to sleep for 10 seconds and retry. From RDF and TF functionality i don't see how they could conflict with each other, you are using clones so there should not be any mirror positions issues or anything like that. SRDF performance might suffer if you are RDFing and cloning at the same time. I don't know if one takes precedence over another.

Thank you all for your expertise.

We have both of this kind of setups; keeping separate DG is simpler one. With mixing you wil have complex commands rather.Also in future migrations this may create troubles compared with seprate DGs

Message was edited by:
SKT

That's why I prefer new behaviour