How to reconnect Veeam Backup Jobs

[philscompany]

Hi,

Hoping someone can advise on this - not a fault as such but more a case of not being sure how this is supposed to work.

Last night I shut down our single VMware host server for a memory upgrade - when it came back up, the flash drive which ESXi was installed on failed.

I replaced the flash drive with a spare and booted it back up. It's still running the same version of ESXi (5.1) but the exact build number is slightly newer.

I've reconnected all the VMs which are on direct attached storage and they're working fine, no problems there.

The only thing is, Veeam now sees these VMs as 'new' and hence my backup and replication jobs all failed to run saying that the VMs were no longer available.

I've linked the 'new' VMs in each job and it's started the nightly backup to NAS and replica to a clone VMware host server from scratch - it's nearly done now - but this means any old backups (we have backups going back several months) no longer have a link to the source VM.

Is there a way to get Veeam to reconnect the backups with the existing VMs so that it realises they are one and the same?

Cheers,

Phil

[foggy]

I've linked the 'new' VMs in each job and it's started the nightly backup to NAS and replica to a clone VMware host server from scratch - it's nearly done but this means any old backups (we have backups going back several months) no longer have a link to the source VM.

Newly registered VMs got new moRef IDs used by Veeam B&R to track VMs, that's why they are treated as new ones. However, this does not mean you cannot restore from existing backups.

Is there a way to get Veeam to reconnect the backups with the existing VMs so that it realises they are one and the same?

Sure, you need to map backup and replication jobs to the existing backup files and replica VMs.

[philscompany]

Thanks, that explains why they aren't seen as the same VMs.

With regards to your second point, are you able to elaborate? I don't quite understand. The backup jobs didn't change and are still mapped to the same repositories, it's the live VMs that changed. I think I've misunderstood something here.

That said, I'm letting the jobs re-run with the 'new' VMs and although the first run is slow while it builds up, it'll presumably be fine once it's finished and effectively back to normal.

[veremin]

That said, I'm letting the jobs re-run with the 'new' VMs and although the first run is slow while it builds up, it'll presumably be fine once it's finished and effectively back to normal.

Correct. Once VMs get new MorefID, they will be considered as new ones from a backup server perspective. New full backup will be performed for such VMs, subsequent runs will be incremental. Thanks.

[foggy]

With regards to your second point, are you able to elaborate? I don't quite understand. The backup jobs didn't change and are still mapped to the same repositories, it's the live VMs that changed. I think I've misunderstood something here.

You need to map jobs to existing backups of VMs that have changed their ID's, so that the backup chains could be continued. However, full job run will be performed after changing VM ID. You can find the detailed instructions on how to do that by following the links referred to above.