How to perform replica failover commit in v5

[DAXQ]

Will do - I plan to write final steps in the end once I get it working as expected.

Cant thank you enough for you assistance through all this - I just hope getting the newer version allows for things to work as expected.

[DAXQ]

To actually see this work - is really a thing of beauty.

So as we have determined, the steps originally listed in this post would be considered the perfect steps required to use Veeam B&R to FailOver commit to the most current FULL replica. However - if you wish to FailOver commit to any OLDER date and time (aka a ROLLBACK replica) - the following procedure should be used (tested and verified on version 5.0.2.230(32 bit) - these steps definitely failed in earlier versions):

Veeam B&R Commited Fail Over Process for RollBack

Basic (just as given by tsightler)

• Failover the VM to the replica
• In Veeam Console select "Backup and Replication"..."Jobs" and delete the replica job
• In Veeam Console select "Backup and Replication"..."Replicas" right click on the Job name and select "Remove from replicas"
• Delete "VEEAM RUNNING" snapshot on target VM
• You are currently running your "Commited" server

Detailed steps:

• 1. Failover the VM to the replica
  • Open Veeam B&R
  • Select Restore
  • Select Failover to replica - Next
  • Select the Repica you want to fail over - Next
  • Select the date/time you want - Next
  • ----[remember this is only for RollBack VM's older than the current full]
  • Enter a reason - Next
  • Click Finish to begin the process
  • A Restore Session window will open your done when you see "Failover completed succefully"
  • Close Session Window
  Verify VM is up and operational.
  2. In Veeam Console select "Backup and Replication"..."Jobs" and delete the replica job
  3. In Veeam Console select "Backup and Replication"..."Replicas" right click on the Job name and select "Remove from replicas" - click Yes when asked to verify
  4. Delete "VEEAM RUNNING" snapshot on target VM
  5. You are currently running your "Committed" server - when time permits, continue with the following steps to "Clean up" your committed server:

CleanUP

• 1) Rename the Virtual Machine in the VIC from VM_replica to VM
  2) Shutdown the VM and move to a Production Spot on the data store (move it out of \VeeamBackup)
  • Shutdown with VIC
  • Remove the VM from the Inventory
  • Move the VM to a different folder on the datastore
  • Rename the folder from VM(###) to VM
  • Re-Add the VM to the Inventory
  • start VM Should get a clean boot
  3) Clean Up the datastore folder, remove any old Veeam Files
  • delete *.vbk, *.rbk and *.vrb files

You should now have a Clean, Fully committed RollBack VM that is running in a production spot on your datastore. If you wish to begin replicating this one, create new jobs in Veeam to reverse things.

[MB-NS]

Hello,

I must miss something, but I don't see a difference between your steps and the steps the OP listed ? (apart from the step involving moving the VM to get it out of the Veeam folder)

[DAXQ]

Essentially the biggest, only real difference and most important difference is:

Full = UnDo
RollBack = No Undo - and you must be using a version of 5.0.2.230 or it will not let you remove the list from Veeam.

I will admit - it is not a very big change, however its pretty significant IMHO - failure to make the change causes corrupt VM's that will BSOD, throw registry errors, and create Hung VM's the you cannot access from host.

[tsightler]

Just to add, remember for the "CleanupUP" section you can also use storage vMotion to achieve this without VM downtime (of course assuming you have this feature).

[MB-NS]

Essentially the biggest, only real difference and most important difference is:

Full = UnDo
RollBack = No Undo - and you must be using a version of 5.0.2.230 or it will not let you remove the list from Veeam.

I will admit - it is not a very big change, however its pretty significant IMHO - failure to make the change causes corrupt VM's that will BSOD, throw registry errors, and create Hung VM's the you cannot access from host.

OK, I understand. The OP didn't list the UNDO step but another user posted a second list, which included the Undo step.
Gostev validated the first one... but not the 2nd one I think.

[DAXQ]

I don't think originally there was any real clarification for doing full or rollback. As tsightler pointed out probably 99% of folks will be trying to just fail over to their last full replica. The only reason I was even working on this rollback type was for the possibility that it may occur - like if your replica is crashing things for what ever reason, or if you get hit with a virus or something and want rollback before it happened.

That coupled with the fact that the version I was using would not even allow you to remove the files (since they were locked by the failover) made things fairly annoying. Its all good now and I have a slightly better understanding of whats happening.

[vfrolov]

Just to add, remember for the "CleanupUP" section you can also use storage vMotion to achieve this without VM downtime (of course assuming you have this feature).

The vSphere Client can move the VM's storage to another datastore (not to the root folder in the same datastore).
Is it realy possible with vSphere Client? or svmotion?

[vfrolov]

In my tests.

The following do nothing:

Code: Select all

$ svmotion ... --vm='[disk array] VeeamBackup/vCenter Server/vCenter Server.vmx:disk array'

The following works as expected:

Code: Select all

$ svmotion ... --vm='[disk array] VeeamBackup/vCenter Server/vCenter Server.vmx:iSCSI-XVS-NAS'

So the "CleanupUP" section without VM downtime is not possible without moving to other datastore.

Any comments?

[tsightler]

Actually, this is probably true, I've never tested attempting to svmotion the VM back to the same datastore. In our environment we replicate to a lower tier storage system. If we were to ever "commit" this we would migrate the commited replicas to the tier 1 storage as part of that process. If you want to perform a "cleanup" on the same datastore, downtime might be required, although it would be very minimal since you only have to move the directory and rename it, a process that is almost instant.

[DAXQ]

Not having any large expensive systems (Fiber SAN or NAS) or utilities (I manually do it all) my down time is really controlled by the speed of the underlying OS to physically move the files from one part of the drive to then next. Over all its not really that bad - and we do not need 100% uptime for our application - 15 - 20 minutes downtime is totally acceptable especially if I can plan for the cleanup on a weekend.

[tsightler]

It won't take 15-20 minutes to move the directory on the same datastore. Moving a directory is virtually instant whether you use the Datastore Browser or command line, since the data itself doesn't have to be copied. If I were attempting to clean up on the same datastore I would probably do something like the following:

1. Shutdown VM
2. Deregister VM from vCenter or ESX host
3. Move/Rename folder
4. Reregister VM
5. Start VM

The whole process would take just a minute or two, not because of fast disks, but because moving files on the same filesystem doesn't require copying all of the data.

[DAXQ]

Totally agree - was going to the far end of what I have experienced. Might be thinking of a time when moved to a separate datastore in the same physical server. But I think its a totally acceptable down time if you done need 100% uptime.

[mburleson]

Same topic.. sorta same line

I have a VM that I replicated from my primary to my secondary site. What I missed/didn't realize was the snapshot.

I need to commit the data in the snapshot to the VM and make that VM primary. I realize the latter portion has been mostly covered here, but my understanding that is right when you know everything is good.

I've ran this VM replica for 2 months now at the secondary and need to move it back to the primary cluster.

I Cannot lose the data that has been accumulated.

I know this may be a basic VMware/Veeam question, but really appreciate the help.

--Mb

[Vitaliy S.]

All you need to do is to follow these steps posted by David:

Detailed steps:
Verify VM is up and operational.
2. In Veeam Console select "Backup and Replication"..."Jobs" and delete the replica job
3. In Veeam Console select "Backup and Replication"..."Replicas" right click on the Job name and select "Remove from replicas" - click Yes when asked to verify
4. Delete "VEEAM RUNNING" snapshot on target VM
5. You are currently running your "Committed" server - when time permits, continue with the following steps to "Clean up" your committed server

[DAXQ]

I think (please correct me if I am wrong) You can delete a snapshot any time. Deleting snapshots does not affect other snapshots or the current state of the virtual machine.

[Faridbo]

[merged]

Hello Everybody

Sorry for my poor english

2 Esxi 4.1 (Esx1 with one VM & esx2 with Three VM)
Vcenter
1 Veeam Backup & replication 5
4 Vms windows 2003

Replication is enabled for my server named : ServerDC1 (on esx1)
The replica is named : ServerDC1_Replica (on esx2)

My Esx1 crashed yesterday
The replica started (ServerDC1_Replica) : Good it started

But when The ESX1 was repaired and restarted, I turned off the Replica on Esx2, and to my surprise the changed datas have also been lost (one directory created on my desktop), The ServerDC1 was turn on but without the directory on my desktop !!

Can someone help me ?
Is it possible to convert a replica to VM (not replica) : for example servdc1_replica becomes ServderDC1

Thank you for all