Moving VMs to a new virtual center.

[dal_eng]

Hey,

I have a large file server that is backed up by Veeam, over the next few weeks I will migrate the server to a new data centre and it will be managed by a different vCenter. If I create a new backup job for this VM will I be able to map the job to the original backup file to avoid another full backup. At the moment we use reverse incremental on a weekly schedule and I would like to avoid a full backup across the Wan at all costs!

Cheers,
Darren

[foggy]

Hi Darren, upon being registered in the new vCenter, VM will get a new ID and will be treated by Veeam B&R as a new VM. This will cause a full backup during the next job run after re-adding the VM, unless you match VM IDs in the database - see this thread for details.

[dal_eng]

Hi Foggy,
I have read through the thread and downloaded the migration tool/instructions. They state that you can't backop from the old vCenter after using the tool. I will be migrated the servers between the datacenters over a 6 week period. For all the other servers I will create a new job, it is only the file server that I want to map to the original backup file. Can i use this tool to just update the ID for one server and continue to backup the VMs still attached to the original vCenter after?

[trackstar]

Hello,

We tried to upgrade from vCenter/ESXi 5.5 to 6.5 but ran into issues. VMware support recommended a new vCenter install which we did. Can we redirect current backup jobs to the new vCenter? Creating new backup jobs will be insufficient because that means we have to keep two sets of backup data and new jobs will take longer to run (machines have to be added in slowly to manage bandwidth ).

We are on 9.5 update 3.


Thanks,
TT

[foggy]

For all the other servers I will create a new job, it is only the file server that I want to map to the original backup file. Can i use this tool to just update the ID for one server and continue to backup the VMs still attached to the original vCenter after?

Then you do not need the tool, I believe, the ID for this single server can be updated manually.

[sstick62]

Does quick migrate avoid the issue with Object with reference 'xx' was not found in hierarchy cache so you can keep your existing backup chain?

[csydas]

Hey Stephen,

Nope MoRefID is the name of the game here, and sounds like VMware has given your VM a new ID. The way that VMware's CBT works with backup applications is that when you run a backup, all that VM data (CBT ID and VM ID) is supposed to be recorded, so that's embedded into a backup file. The backup application expects a VM MoRefID of X, where X is the ID the VM had when you started the backup.

I suppose you can hack your way around this in the DB, but I'd just bite the bullet and do a new backup, doing whatever you need to do.

[sstick62]

Thanks Harvey,

I moved the disks from one datastore to another on the same ESX host. Didn't think it would change the VM ID. Live and learn.
If you can hack the data base then why doesn't Veeam do this automatically?
In large environments the customer now has to do another full and start another chain.
In the case of this one ESX server I'm talking 20TB of extra full backups.

Thanks for replying!

[foggy]

There's a utility that might help in such cases.

[rowebil]

Hello!

We upgraded VMware ESXi (vSphere) and vCenter for several of our clients.
Now a few clients have very large file servers and can take more than a day to create a full backup.

Especially with backup copy jobs to the cloud or offsite repositories -- the copy interval expires and even if I set it for 14 days, the transfer speed is so slow that it expires and will never complete.

We do have existing backup copy chain files on the cloud or offsite repository. It just wants to create a new backup copy.

Is there any way to use the existing backup chain file so that this offsite backup copy job will back it up incrementally instead of a full active backup?
So then it will only transfer incremental instead of a full backup.
Can I copy the files (besides the backup copy job file) into the new backup directory? Then start the backup copy, it sees that there is already a full and/or incremental, it scans the local backup data for changed blocks, and only transfers those blocks instead of a full incremental.

The same happens locally...
We upgraded vCenter 9/24.
If you look under Backups > Disk, you can see TWO job names 'FS01' one with the last backup of 9/24 and the other with last (failed) backup of 10/30.
Is there any way I can copy the data from the FS01 from 9/24 into the folder of 10/30 so then it recognizes a full backup is there and will only process changed blocks?

[rowebil]

Ah.

I just looked and forgot to mention that perhaps moving files from one folder to the new one wouldn't do it... because it's one large backup job.
It isn't separate so that FS01 has it's own backup job -- then I can go into the backup repo, find the FS01 folder, copy those contents inside of the FS01_1 folder which is the backup job that keeps failing because it's so large and the transfer speed is 700 KB/s.
I understand it takes the machine ID from vCenter and that is what is causing Veeam to do a full backup instead of an incremental using the data that is already there.
Could I change information in the VBM file so that I point the current FS01 to backup using the old FS01 backup from 9/24?
So 9/24 may say machine ID 124 backs up in that folder, and the current machine ID is 126. If I modify the VBM for the 9/24 backup and change it from machine ID 124 to 126.
So then it will say "Hey, machine ID 126 belongs here. Last backed up 9/24 - initiate CBT and backup."

Instead of saying "Hey, we have a backup for FS01, but the machine ID is 124 and the current machine ID is 126 so let's start a new FULL BACKUP."

[foggy]

Hi William, your VM IDs have changed during VI upgrade causing the observed behavior. There's a tool to address such situations, however, I'm not sure it works in case you've already started the jobs pointing to the new VC. Please see above for details.