One of the first things that I noticed after upgrading my Veeam Backup and Replication to version 6 was in my replication jobs list. All of my replications jobs from version 5 had been labeled as a Legacy Replica. Now, being the type of guy that I am I didn't want to have Legacy anything hanging around. Plus, without recreating these jobs in v6, you cannot take advantage of some of the new enhanced feature sets like replication to a cluster, re-IPing, and production/network assignments.
This is the process I used to 'recreate' these jobs in order to take advantage of all the new features.
To start out I guess I shouldn't have really titled this post 'converting' because what you are actually doing is recreating these jobs and using the new 'Replica Mapping' feature to map to your original replica's.
So, first step, right click in your jobs window and chose ''Replication" to create a new replica job. In the first window that pops up you can see some of the features that I spoke of above. For this example however we only need to use one 'Low connection bandwidth [enable replica seeding].
Continue through the wizard as you normally would, selecting your source VMs, Replica Destinations (notice the new Cluster/Resource Pool/VM folder options), and Job Settings. One note, for organizational purposes you might want to select the exact same location and use the same Replica name suffix as you did in the v5 job that you are recreating. It might make things a little easier for you…
When you get to the Seeding section this is where the magic happens. You can now map the VMs in your new job to existing replica VMs, or you could even seed your initial replica from a backup repository residing at your DR site if you have a backup of it. (this is awesome!).
In this example I'm simply going to point the VMs in my new job to the replica VMs from my original v5 job. Check the 'Map replicas to existing VMs' check box
Here is where you can either manually specify which VMs to map to the replicas, or you can have Veeam use its' magic and detect it by itself, Either way, select your VM you want to map and click 'Edit' to do it manually, or simply click 'Detect' to use the magic.
The rest of the wizard should be pretty straightforward as the options are very similar to those in v5. Once you have completed and saved the job give it a whirl and make sure it is working as expected. Be sure to disable your old v5 'Legacy Replica' job as we do not want this running along with the new one. One of the new features in Veeam v6 is the fact that they have improved how they store their replication points of a VM. In v5 the older restore points were saved as a roll back file (.vrb) and could the replica could only be rolled back by the Veeam server. Now, in v6 all restore points are native VMware vSphere snapshots taken at a point in time. Thus, in the event of a failure of your Veeam Backup and Replication server you could still power on a replica VM to any point in time just using the vSphere Client (completely independent of the Veeam Server). So, after a few runs you should see your restore points from the vSphere Client Snapshot Manager.
The newly created v6 job has no knowledge at all of the older .vrb files that are associated with the v5 job nor does it know about the older retention policies that you have setup so there is a little manual cleanup involved. Once you are comfortable with the amount of restore points and retention that you have in your new job, you should go and remove the old VMs from the Veeam database. To do this, go to the Replicas – Right click on your old job and select 'Remove from replicas'. We do NOT want to delete as the new replica's are actually using the same vmdk and vmx files as the old ones.
After you have removed from replicas you can now browse to the datastore where the replicas were hosted and delete the unused .vrb files. Use the vSphere Clients' Datastore Browser or whatever your preferred way to get to the datastores are and find all of the older .vrb files. These are safe to delete (as long as you are sure you will never need to restore to them again 🙂 ) You can also go and delete your 'Legacy Replica' job as well if you want, as you should probably never run this again.
And there you go. You should be all setup with your new VMware Replica job that is able to take advantage of all of the new and enhanced replication features that Veeam Backup and Replication v6 has to offer. Again and as always feel free to leave any comments, questions, concerns or corrections in the comments box below.
Thanks for the post! Great explanation!
Thanks Doug…Congrats on the release!
I followed this article to ‘convert’ my v5 replica jobs to v6 and now when I run the new v6 replica job (mapped to exisitng v5 replicas) it takes ages to complete the new replication. For example I started one over an hour ago and it’s still on 0%! Why are they taking so long?
Hey Mark,
Is this still the case? it worked fine for me…what does the status say in the logs? I’ve seen where it is ‘waiting for resources’ due to the concurrent jobs setting on the proxy. Hope it’s worked out for you…
It looks like the first time you run the job it spends a lot of time “Calculating digest”. From what i can tell the remote backup proxies reads the entire VM to establish the baseline for future replication jobs and only needs to be done once. I will take this over reseeding the backup jobs any day!
About the slow 1st backup. There is a hotfix out for this. Its on the download page of veeam 6
Thanks Dale, I’ll go and check out the release notes!
But after the first run, the mapping is to be disabled?
Great post, thank you. A few minor questions:
I wanted to give the new job the same name as the old legacy job. I did it by renaming the legacy job first and giving the new job the correct name. Hope that was sensible.
Afterwards, I then tidied up and have removed from replicas and deleted the old vrb files. I still have a vbk file with an old date on it in the datastore. Can I safely delete that? (I do not need a replica from that date)
Once the conversion has finished, should you then go back in and edit the new job to remove the low connection bandwidth (replica seeding) tick?
You should be ok to go ahead and delete it, but to be sure, just check your backups/replica’s to make sure you arn’t actually still mapped to it within a job. Right click on your backups and chose properties and you should see what files they are actually using. And yes, you can remove the replica seeding tick as once you are initially seeded you should need it anymore… Thanks for the comment 🙂
Hello,
I recently moved couple of VMs from Repository to another
Repository on another Server. I have created a new Job and selected
multiple VMs. How can I map existing backup Jobs “.vbm” on the new Repository to match existing backup jobs?
I found a way that I can map one-by-one, but is this the right approach?
I don’t think this is the right way of doing it. because the earlier
jobs are each has it’s own .vbm file and .vbk file. A job with multiple
VMs will have one .vbm and one .vbk, but this VBK will have all the VMs
on it.
Appreciate your fast response.