VM moved to new vCenter

[samuk]

HI,

Is there anything specific i need to do?

We have upgraded our VC from 4.1 to 5.5 (ended up being a clean install in the end)

backups are failing, if i try to re scan the VC from Veeam i get this

13/03/2015 11:02:09 Error [PrVCsrv01] Disks and volumes discovery failed Error: Permission to perform this operation was denied.
13/03/2015 11:02:09 Error Host discovery failed

Veeam Version 8, hosts are still on 4.1

Any help appreciated,

[Vitaliy S.]

Did you preserve old vCenter Server record in Veeam backup console while doing clean installation of it? In this case you will need to remove your old vCenter Server, add new one and re-configure your backup/replication jobs.

P.S. Please note that you will have full run (not incremental) for backup/replication jobs, so plan your jobs schedule accordingly.

[samuk]

thanks...have recreated the jobs - is now working

[kkuszek]

So after restoring several VM's from backup to different hosts/datastores and recovering from a failure none of my VM's are backing up. I could easily just add the new ones to the existing jobs or re-create the jobs... but my destination is rather tight on space and I don't want to duplicate while I wait for previous backups to roll off. Is there a way to re-point an existing job backup history to the restored copy of the VM so further incrementals and backups build off the existing repository?

[Shestakov]

Hello Kurt,
Yes, you can map the recovered vms to the existing backup files. Keep in mind that the first run of the new job will be Full backup.
What backup method do you use?
Thanks.

[alanbolte]

To clarify:
With reverse incremental method, backing up the 'new' VMs to the same job the 'old' VMs were in will save space because while the next backup session will need to read the entirety of each VM, the data it is writing into the backup file will be at least partially deduplicated out. For any other backup method you'd be best off manually running an active full or using an entirely new job, because you won't save any space by using the existing chain, and putting a bunch of full backups into an incremental backup file just increases your chances of having more problems when you go to merge or transform those files.

[jb1095]

Hey all,

We have brought up a new vCenter(5.5). We still have our old one up(for now) but plan on taking it down once everything is migrated over to the new vCenter. The problem is that all our backups are doing new full backups and we may run out of space because of it(or at least get very low). Is there any way to repoint the backup jobs to the new vCenter so we can continue to use the old backup sets instead of creating brand new ones? We are on Veeam B&R 8 btw, newest updates.

[Shestakov]

Hi Jon,
Correct, after the migration you can keep using your jobs.
As described above, after migration VMs` Moref IDs change and the first run is a full backup. Please review the thread and ask questions if you have any.

The problem is that all our backups are doing new full backup...

Do I understand correctly, you meant that backup jobs are doing full backups after vm`s migrations? Or you just scheduled your jobs to do full backups only?
Thanks.

[jb1095]

Hi Jon,
Correct, after the migration you can keep using your jobs.
As described above, after migration VMs` Moref IDs changes and the first run is a full backup. Please review the thread and ask questions if you have any. Do I understand correctly, you meant that backup jobs are doing full backups after vm`s migrations? Or you just scheduled your jobs to do full backups only?
Thanks.

Yes, you understand correctly, after the VMs get migrated, the first job is a full backup. I want Veeam to use the existing backups rather than create a new full for all these VMs. I will read through this thread.

[jb1095]

ok. I have read the entire thread and come back to my original point. I will try to be a little bit more clear. Due to storage limitations, we do not want every one of our jobs first run to be a full backup when we already have multiple full backups of the same VM in the repository(we must keep these for retention policy reasons). I understand that Veeam sees them as new VMs as they get new ref-ids when migrated to a new vCenter. What we have done on these jobs is the following:

1:) edit the job, remove the VMs(these had a path to our old vcenter)
2:) Add the VMs back to the backup job(this time they are pathed to the new vCenter)
3:) On the storage tab of the job, we click "Map Backup" and point it to the same job it has always pointed to.

When the first job runs, it is a full backup. All backups after that will be incrementals as usual.

Is there any way to get Veeam to recognize that it already has these VMs backed up and run incremental for the first job instead of full. I have read there is some sort of script that needs to be run that modifies the ref-id in the Veeam database to accomplish this.

Am I missing something obvious here?

[Shestakov]

Yes, you are correct. There is a script you can run to keep the id unchanged.
You can obtain by contacting Veeam technical support. Once you have a support case number, post it here and I`ll escalate it to the right engineer.
Note, that if you've moved VMs to new vCenter, and have already run jobs, there is nothing we can do in this case. The mentioned script should help when nothing has happened since VMs were registered under new VC. Thanks.

[jb1095]

Yes, you are correct. There is a script you can run to keep the id unchanged.
You can obtain by contacting Veeam technical support. Once you have a support case number, post it here and I`ll escalate it to the right engineer.
Note, that if you've moved VMs to new vCenter, and have already run jobs, there is nothing we can do in this case. The mentioned script should help when nothing has happened since VMs were registered under new VC. Thanks.

We did run one of the jobs and it is almost done(98% right now). The others have not been run yet as they all still point to the old vCenter but were actually migrated to the new vCenter. I assume the script will work for all those VMs? My support id is 00845081. Thanks so much for your help!

[jb1095]

I just received this email from Dale at Veeam support to which I replied with the content of this thread. We shall see what happens. Thanks so much for your help.

"Hello Jonathan,

Unfortunately we are not able to update the database to cause Veeam to see the new ref-ID to be the same VM as the old ID. Because of this, when anything causes the VM to get that new ID the VM is processed as a new VM. These jobs will have to process the VMs as a new VM since the ref-IDs have been updated on them.

Thank you,
Dale Everett
Veeam Support"

[Shestakov]

Hi again Jonathan,
We discussed the case with support engineers and managers, and agreed to provide you the script.
Be notified that despite the fact that the script worked fine so far, it`s still not fully tested by our QA team. That`s why Dale Everett told you that we can not help you with ref-ids.

One way or another I provided your support case to the engineers who participated in the script`s creation and have experience in its implementation. Thanks!

[jb1095]

Hi again Jonathan,
We discussed the case with support engineers and managers, and agreed to provide you the script.
Be notified that despite the fact that the script worked fine so far, it`s still not fully tested by our QA team. That`s why Dale Everett told you that we can not help you with ref-ids.

One way or another I provided your support case to the engineers who participated in the script`s creation and have experience in its implementation. Thanks!

I got an email back from Dale last night and he told me I was escalated but have not heard anything since then and we are running low on space. If we allow all the backups to run this weekend, we will probably run out of space and that is very bad. So at this point, I am trying to find a clean way to remove some of the old restore points to make room. I "tried" to move one of the incremental backups to a test folder and rescan the repository, but it did not remove anything. I then tried to follow instructions on removing some restore points by selecting "delete from disk" but it actually deleted all of its restore points so now I have to do a full backup of it again. (Thank god it is a fast full backup job to re-do). In the interest of speed here, is there a way for Veeam to remove SOME of the restore points and not all?

Also, since we - re-mapped these jobs to the new vcenter, since Veeam is still showing tons of restore points, are we able to reduce the retention period, so that it just removed the oldest ones and if so, will I get that space back immediately or no? I am very concerned that we will run out of disk space.

[Shestakov]

As far as I can see your case has been escalated to the right engineer.

I then tried to follow instructions on removing some restore points by selecting "delete from disk" but it actually deleted all of its restore points so now I have to do a full backup of it again. In the interest of speed here, is there a way for Veeam to remove SOME of the restore points and not all?

You can delete backup chains manually, but not particular incerements or Full backup of the chains, since it will make other increments of the chain useless. In case of reverse incremental chaining, you can remove the oldest incremental file manually, if required. The job will not fail, however the corresponding restore point will still be displayed in the Veeam B&R UI and then removed, when retention comes.

Also, since we - re-mapped these jobs to the new vcenter, since Veeam is still showing tons of restore points, are we able to reduce the retention period, so that it just removed the oldest ones and if so, will I get that space back immediately or no? I am very concerned that we will run out of disk space.

The deletion of restore points happen after adding a new restore point. Veeam Backup & Replication checks the retention policy set for the job and removes outdated restore point(s) from the backup chain.
Thanks!

[Tarqy]

I'm planning a full rebuild of our vCenter server with a new VCDB and was already aware of the implications this has on existing backup jobs. I'm happy to run full jobs as we have sufficient time during the backup window to accomplish this however we now have backup copy jobs associated with these.

Is anyone able to explain what would happen to these jobs? Would they just keep running as forever inc or as I suspect to be the case would a full backup copy job also be required?

I don't have the disk space or bandwidth to push another set of full backup copies across our WAN link.

I'd prefer to use this script that has been mentioned here to modify the Moref IDs in the DB but when I raised a ticket with support I was told they couldn't provide it.

[Shestakov]

Hello Barry,

I'd prefer to use this script that has been mentioned here to modify the Moref IDs in the DB but when I raised a ticket with support I was told they couldn't provide it.

Indeed the script is being tested and our support doesn`t provide it recently.

Is anyone able to explain what would happen to these jobs? Would they just keep running as forever inc or as I suspect to be the case would a full backup copy job also be required?

Backup copy jobs copy restore points to the secondary backup repository. Yes, backup copy retention policy is similar to backup forever-incremental one. Here is our current recommendations about the chains length and full backups:

Now we recommend the ultimate VM backup architecture:
1. Short retention on fast primary storage.
2. SureBackup of backups on primary storage (recoverability testing).
3. Backup Copy to secondary backup storage to meet 3-2-1 rule (using GFS for data retention longer than a few monts).
4. Backup Copy job's health check to detect any backup file data corruptions that may have happened in-flight, or at rest on either side.

Specifically to Active Fulls: I don't recommend scheduled Active Fulls at all, but perhaps doing them manual only, as needed only in the following circumstances:
a) SureBackup detects unrecoverable backup, or backup file data corruption.
b) You want to reduce VBK size (after rearranging jobs or deleting lots of VMs), or its fragmentation.

And remember that Backup Copy jobs do recovery from (a) automatically, and can do (b) periodically with Compact functionality, which is the reason why we don't even provide the ability to perform Active Full on Backup Copy jobs.

Thanks.

[Tarqy]

I'm running a setup with short retention on fast disk with a copy job associated with the backup job to a Data Domain for long term retention (GFS). We then off-site this data using Data Domain replication to a 2nd Data Domain at our DR site.

I simply want to know what the repercussions are on a backup copy job if I modify the existing backup jobs to point to the new vCenter server/VM's. I know that the backup job will need to run an active full but what happens when the copy job runs? Will it also perceive this to be a completely new VM and run an initial full copy?

[veremin]

Will it also perceive this to be a completely new VM and run an initial full copy?

Correct.

[Shestakov]

After VMs`migration, Moref IDs change therefore the first run of backup jobs will be an full (to be exact it will be a .vib file with size of active full). Same is for backup copy jobs.

[VladV]

We are in the same boat as jb1095.

We can support the extra space needed for the main backup jobs but not for the backup copy jobs that use another repository.

Now that vSphere 6.0 is out we plan to install a fresh copy of the vCenter as VCSA and we have to go through this change in IDs. Do you know if the script will be available at some time or if there is any other solution for us in this case?

Thanks

[Shestakov]

Hello Vlad,
Just talked with QA, the script is being tested-fixed. In the best case scenario it may be available in a week. But no promises.
Thanks!

[Tarqy]

Hello Vlad,
Just talked with QA, the script is being tested-fixed. In the best case scenario it may be available in a week. But no promises.
Thanks!

Could you let us know when its available here, I think support are about to close my ticket and I can track this thread easily.

Many Thanks.

[veremin]

Yep, the updates regarding the given solution will be provided here.

It's important to note that the script/tool will be given to support engineers only, not to general public, as we want for direct modifications with product database to be done under direct supervision of versed engineers.

Thanks.

[VladV]

So, to understand correctly, when the script will be available, we should be able to contact Veeam support and the engineers will be able to modify the Moref IDs of the transferred VMs?

[Shestakov]

That`s correct.

[tschmi]

Hi,

are there already some news for the script?

thanks, regards

[Shestakov]

Hi,
The testing is done. You can contact Veeam support to make use of it.

[cjack03]

I have opened a support case with the #00938316 but have been told that the script is being tested by the creator and can't be
published. Is there any chance you could have a look for me. My need arises from this situation:

http://forums.veeam.com/veeam-backup-re ... 28580.html

Hi,
The testing is done. You can contact Veeam support to make use of it.