Permanent Failover and Failback

[Rumple]

One of the things I need to plan for is what happens if I have to do a failover (lets say SAN controllers die and SAN goes down but no data is lost) and eventual failback
Failing over is simple enough...follow the wizard. But of course I don't want to stay in that situation for long because I don't want snapshots on my now "production" VM's.
So I need to perform a permanent failover until SNA is repaired.
So..I get the SAN working again and online and it contains all my TB's of VM's....
What is the approach to replicate backwards now?
I've tried doing a new replica job and pointing it to Source and then trying to put it on the same Volume/name as the existing SAN based copy...but that doesn't work. Errors about the VM already existing.
Do I need to back those VM's up again (so I can recover more recent data then was in the replca) and then seed the replication with the back (but of course that recent data will get deleted when I replicate DR to SAN copy because replica was slightly older then the last poweron of the SAN copy.

[tsightler]

Failback is already built into the product. Just walk through the failback wizard and the changes will be replicated back.

[Rumple]

So. I perform a failover to DR because prod went down (temporarily)
I then perform a permanent failover (because you should never leave a snapshot on a VM thats going to grow substantially and because performance is impacted)
At that point you have no ability to failback as the replica;s gives you 2 options...delete replica or delete from disk...there is no failback possible.
once production is back without deleting the former production and re-creating your replica back on production (and doing failover)

At this point I think the only recourse is to delete former production VM and then do a new replication in reverse telling it to use the backup job as a seed (thats hopefully stored on destination side), then I have to do that all over again in reverse to get back to a Prod/Dr replication.
The only way I can think around this is if I perform a failover and then manually delete the snapshot on DR....so that I can run it as production and then hopefully fail back....

[Gostev]

So. I perform a failover to DR because prod went down (temporarily)
I then perform a permanent failover (because you should never leave a snapshot on a VM thats going to grow substantially and because performance is impacted)

That is not the right way to use the product. Permanent Failover, as the name implies, is designed for when you have decided to make replica your new production VM forever. If that is not the case, then you just keep the VM in failover state while you are fixing your production site (presumably, you will want to do it quickly - within a few days), and then perform failback. Snapshot will not grow too large during this timeframe, so snapshot size is not to worry about.

And, it is not true that I/O performance is impacted when VM is running off the snapshot.

[Rumple]

mother F%^%$ - I just realized that if I use the seed option I do have to specify a a repository to use, but it will also detect and use an existing VM under the same section.
bit clunky to do it that way when the seeding option should be seed from repository or seed from existing vm...might make it simplier to understand.

[foggy]

mother F%^%$ - I just realized that if I use the seed option I do have to specify a a repository to use, but it will also detect and use an existing VM under the same section.
bit clunky to do it that way when the seeding option should be seed from repository or seed from existing vm...might make it simplier to understand.

I don't fully understand what confuses you here. These options are provided for different scenarios: the one for seeding a replica job from the VM backup and the other for mapping the job to an existing VM on the target host.