How do I failback if replicate metadata is gone?

[danswartz]

I had a failure of the NAS backing my vsphere datastore. Unfortunately, I also had the replica metadata in a veeam repository on that datastore. I can see the replica VM in the vsphere datastore of the backup host, but I can't see any way to failover to it and then failback to production (giving option #3 to fully copy everything back to production host), since the replica metadata is missing. All the googling has shown me is comments that 'the next time you run the replication job,veeam B&R will detect the missing metadata and recreate it...' Unfortunately, I seem to have a chicken&egg situation here. The source VM is gone, so the replication job won't/can't do anything, but the metadata is gone, so that VM's replicas do not show up in the list of replicas to allow failover/failback. Am I missing something here? If I absolutely have to, I suppose I can make a copy of that replica VM, coalesce all the snapshots, and copy that VM back, but that seems suboptimal. Kinda of a bummer there is no obvious way to point B&R at a vsphere datastore and tell it 'recreate all replica metadata from here!' I tried running the replication job anyway, and it failed as expected for the missing VM, but it also failed for every other VM, throwing errors for each existing VM like such "1/12/2014 8:31:13 AM :: Processing 'PBXinaFlash' Error: The name 'PBXinaFlash_replica' already exists", so it seems like the advice about 'just re-run the job and it will re-create the metadata" is not correct (or at least not in my case?)

[Gostev]

Hi, actually replica metadata is not required for failover, so the reason why you do not see the VM in the list of replicas available for failover/failback must be different. Replica information is stored in the configuration database, not in the replica metadata. Perhaps something else also happened in addition to the things you have mentioned, for example somebody delete the replica from the configuration database (there is an option for that). You can investigate this activity through the debug logs with support, if you'd like.

Remember that you can always just power on the replica VM manually as the last resort, even when you lose everything at all.

Thanks.

[danswartz]

Thanks, Gostev. At this point, I don't know what was going on. Possible something else got messed up for sure. I was stressing out because that VM has to be up tomorrow morning, and I was going to be away all day today. I finally used vsphere client to clone the replica (which consolidates all the snapshots), renamed it to something else, and fired it up. Lesson learned - I had been meaning to run a ZFS snapshot replication job to copy config/metadata info to a different pool, but kept putting it off. All seems okay now...

[veremin]

Hi, Dan,

Glad to hear that you're up and running now.

In case you face the similar issue again, probably, the best way will be to power on target replica manually and recreate the existing replica job, so that, it goes in the opposite direction. This way, once the replication cycle is finished, you will have fully functional VM in the production site, to which you can failover, using the corresponding functionality.

Thanks.

[danswartz]

Oh, okay. Yeah, that makes a lot of sense. Thanks much!

[veremin]

You're welcome. Feel free to ask, should any additional help be needed. Thanks.