Committing A Veeam Replica Failover

Over the last few weeks I’ve really had the opportunity to put Veeam Backup and Replication to the test.  I’ve completed multiple restores (using Instant VM recovery, Entire VM and by picking just single vmdks) and it has saved us like a champ many times.  Today we ran into a situation where another restore was needed, however this time, since some of our replicas were now on some decent storage I decided to give the failover a shot.

Failing over to a replica is pretty straight-forward and in most cases shouldn’t even need any supporting documentation.   Where I ran into some questions was when the failover was complete.  In essence, I had my VM up and running within minutes, end users were happy as they were able to access the application, but the VM in question was now running on some lower tier storage and was experiencing a little bit more latency than it normally would running on our production storage.  I found documentation in the B&R user guide on how to ‘Undo’ a failover, but didn’t see any on how to commit a failover.

So, below is the process I followed to commit the failover and get this VM back onto production storage and get my replications jobs functioning again on the ‘new’ replica VM.

1.  Remove the Veeam Backup Running Snapshot – Veeam creates a snapshot before powering on the replicated VM.  By reverting to this snapshot you are able to get the VM back to its state before you performed the failover, thus giving you the option to undo.  In this case, I had no plans of undoing this failover as I needed this replica for production use so I deleted it using the VI Client.

2.  Storage vMotion your replicated VM to your production storage.  – This does a couple of things.  First off, if you are like me and have some lowered tier storage to host your replicas, it gets the VM to your faster spindles.  Secondly, your replicated VM files are stored inside their own directory in a folder called VeeamBackup on your datastore.  The storage vMotion will also do the ‘cleanup’ so to speak of your folder/file names, aligning them with your VM name.

3.  Remove original VM out of the replica job – Simple task really, if you only have one vm / job, just delete your replica job.  If you have multiple VMs / job, open up the properties of your job and remove the respective VM from the list.

4.  Undo the failover – Don’t worry, this won’t power down your replicated VM as Veeam now has no idea where it went (since the svMotion).  One note however, be sure to check the ‘Force Lock Removal’ box as shown below in order to release the locks on the replicated VM.

The following steps are completely optional…

5.  Remove original VM replicas. – Find your VM under the replicas section, right click and delete from disk.  This will clean up all of the replica restore points from the original VM.  Depending on storage space available, I sometimes do not perform this step.  By leaving the restore points there you it does give you the option to do more restores from the original VM if need be.  Your choice really…

6.  Add the newly recovered VM back into your replica job. – Easy one right!  Add the new VM that you have just failed over to back into the replication job in order to protect it from whatever caused you to fail over in the first place.

These are just the steps that I take to commit my replicas.  As always, I’m sure there are many different ways to do everything but this is the easiest way I’ve found to accomplish this task.  Certainly, if I’m missing something or going way off the hook on something please leave feedback and let me know…  Also, from what I’ve heard Veeam Backup & Replication v6 will have the options to permanently failover to a replica built right in!