How to correctly tidy out after Failover to replica?

[vfrolov]

Hello,

After successful Failover to replica I'd like to use it in production (on destination host).

Is there any manual that describes steps needed after successful Failover to replica?

IMO it should include:

1. Removing records about Replica and Replication Job from the
Veeam Backup configuration database (the Veeam Backup does not allow
to do it after Failover to replica).

2. Deleting not needed files from the destination storage (vrb/vbk/rbk ...).

3. Removing Veeam Backup's Snapshot from replica VM.

4. Rename replica VM (for example rename "vm_name_replica" to "vm_name").

5. Move VM folder from VeeamBackup folder to root folder (optional, because
it require to do power off for VM).

Thanks,

Vyacheslav.

[Gostev]

Hi, here is a good recent summary by one of the users:
http://www.veeam.com/forums/viewtopic.p ... 194#p18191

[vfrolov]

Thanks Anton!

I've just tested "failover commit" procedure with v5.0.
Here is the results:

- delete VEEAM snapshot using vCenter
- rename VM in vCenter from "vmname_replica" to "vmname"

It's OK.

- remove replica from the list of replicas in VEEAM

the Veeam does not allow me to remove replica from the list with error:
This backup file is locked by “…” job, and cannot be deleted

I also tried to remove replica after deleting replication job but w/o success

Any ideas how to remove replica from the list?

- delete/reconfigure replication job to account for new source and intended target

It's OK.

- delete vrb files from underlying storage as we no longer use these restore points
- delete replica.vbk and running.rbk files (please confirm)

IMO all vrb/vbk/rbk files should be deleted. Is't it?

Thanks,

Vyacheslav

[Gostev]

Do you have the job stopped? Or is it removed already? You may want to contact support for assistance with this.
Yes, the files you have mentioned are no longer required and can be deleted.
Thanks!

[vfrolov]

Yes, the job was in stopped state, last result was success and I've disabled job before failover.

automation of the above mention process will also follow in the future release. Probably we need to get rid of VeeamBackup folder as well...

It sounds good. Is the any time-limit?

Thanks.

[Gostev]

Beg a pardon?

[vfrolov]

Are there any target dates for "automation of the above ..."?

[Gostev]

Ah, no - not yet... too early to say, we just released v5 but sometimes in 2011.

[arthurp]

Hi Vyacheslav,

Did you get this issue resolved? I have written the summary for "failover commit" that Anton is referring to and this procedure worked for me on multiple occasions in v4. However, we ran into the same problem as you did in v5. I've just opened the ticket with support and will update this topic upon resolution.

Thank you

Arthur

[vfrolov]

I've opened a ticket too. The last responce is: "this issue will be fixed in the version 5.0.2"

[tfleener]

I am experiencing the same issue, just opened up a support ticket.

[arthurp]

Hi Anton,

I can see more posts on a related thread "How to correctly tidy out after Failover to replica?" Now, that this has been an issue for more users, I expect that developers will deal with this issue without delay (see vyacheslav reference to v 5.0.2). In my case I was able to track it down to database level, where some records were not deleted and this resulted in replica locks. It is quite disappointing as one of the most used VBR features for me was the ability to migrate VMs across virtual infrastructure. As our environment was significantly upgraded over the last several months (hardware) and ESX went from 4.0 (including 4.0.1 and 4.0.2) to 4.1 it actually gave me confidence that our replication really works - we migrated domain controllers, SQL server, file server, MS Exchange 2003/2007 - the product is very good. Additionally, we were able to eliminate backup testing you usually need with tape backups as all our failovers worked flawlessly - until this issue with replica locks.

Thank you

Arthur