Full VM restore - ID retention

[Bunce]

Does a full VM restore retain the VM identifier (in Virtual Center)?

If not, wouldn't all existing jobs that contain that VM then become be invalid and need to be reconfigured or reseeded in the case of replication jobs?

[Sethbartlett]

Full VM restore does not retain the VM identifier in your VC because it is a new VM, all jobs will no longer work as they are not pointing to that VM and you will need to re-add the VM back into your jobs and re-seed/full for that new VM.

[Bunce]

Wouldn't it be safe to assume that if the user selects to restore over the existing VM, that they don't want a 'new' VM?

I realise you can do select to restore VMDK's / VMX's individually etc, but if a user quickly wants to restore a VM that has crashed for whatever reason, they are generally going to select the 'Full VM Restore' option, with the belief that they are restoring 'everything' to how it was at the time the backup was taken, including identifers, storage location, network adapter mappings etc.

[Vitaliy S.]

Andrew, all settings except for VM unique ID will stay intact. When you register VM it receives a unique ID automatically from vCenter Server, besides I assume that ChangeID (CBT) will also be flushed. That means that you will have a full backup job run anyway.

While I agree with you that keeping VM ID might be a good idea (not sure it is possible with vCenter Server though), I should say that restoring full VM is a rare case, so it shouldn't be too hard to edit the existing backup job.

On the other hand, imagine that you're restoring to another vCenter Server, how should this work in this case?

[Gostev]

That's one of the reason behind our recommendation to setup job using containers versus adding individual VMs - not having to edit the job after VM ID changes. This can happen not just because backup/restore, but simply from re-registering VM during troubleshooting etc. Unfortunately vCenter does not allow setting unique ID through API (understandably, these kind of things require single point of management), so preserving ID would require some workarounds and thus will complicate full VM restore code. Which is why we do not have this today. Nothing is impossible, of course...

[Bunce]

I certainly should have double checked before initiating the restore - I actually almost went for just a VMDK restore, but needed to get the VM up quick (happens to have multiple disks) so went what I thought was probably the fastest option to get underway - a full restore.

I guess I was used to a different workflow, where the Full Restore & VMDK/VMX restore options where combined. Simplified it would be:
* Restore VM -> Do you wish to Overwrite (Y) -> Select Disks To Restore-> Restore VMX (Y/N) -> GO
* Restore VM -> Do you wish to Overwrite (N) -> Select Disks to Restore -> Select Storafe -> GO

I didn't realise that the first option required the orginal VM entry to be deleted. Is it possible to restore VMX and VMDK without deleting orginal VM from Virtual Center? EG just overwriting VMX and VMDK files?

I don't recall getting a warning that the VM ID wold be lost, so might be worth putting that in? I think I did get a warning about overwriting the existing VM though..

We use containers for almost all our jobs except replication so no issues there. Its more the fact that Veeam will see it as a completely new VM, therefore requiring re-seeding to external USB for replication jobs, presumably a new full backup + CBT loss, additional space utilisation in the backup target (albeit minimsed by dedup), the reporting per-VM 'chain' will presumably be broken (eg in Ent Manager), as will the backup history of the VM when selecting Restore Points, effective retention policies will be affected (eg old VM will now be seen as 'deleted'), etc.

I've always thought a 'mapping' feature would be of benefit to Veeam, where (possibly multiple) VM ID's are mapped to a 'Veeam ID' for each VM. So in my scenario above, I'd map both the original and newly created 'Virtual Center' VM's to the single VM entity in VEEAM. All Veeam Backups / Reporting / Retention operates off the latter.

Ideally, Veeam could then instruct the backup engine to direct backup/replication of a 'new' VM to the 'old' VM that already exists in the backup target. Various validation checks would need to be made to ensure mapping compatibility / integrity / one-to-many relationships etc, and I'm guessing there could be CBT issues, but from a high level I can't see any other obvious limitations?

This could come in handy for quite a number of issues we see posted where VM ID's are lost (eg new Virtual center installations, Host based VM relocations, VBR server backups, etc). It would also likely solve the other reporting and retention issues listed above de to the 'link' between VM's being maintained.

[Gostev]

We will research how hard would it be to implement full VM restore without VM ID overwriting. If we find an easy way, we will add this into v6. Thanks.

[pparks1]

I should say that restoring full VM is a rare case, so it shouldn't be too hard to edit the existing backup job.

Well, for testing and such, doing full restores of an entire VM is pretty common...at least for me. While I would like to be able to simply restore .VMDK files, that process will restore a previously configured thin disk as a thick disk which isn't ideal. When I restore the entire VM, I get my thin disk back as well.

[Gostev]

Disk level restores support restoring thin disk as thin in v6.

[mlichstein]

[merged]

Hello,

I'm currently testing Veeam B&R in our environment (vSphere 4.1), and have an issue with continuing a backup job after performing a restore. My scenario is like this:

I create a VM (backup-test) running our standard 2008 R2 template.
Create a new job to backup this single VM.
Run the job at least once.
Shut down the VM and then perform a full restore.

The restore works fine, but if I try and run the backup job again it fails because it cannot find object backup-test. If I edit the job, remove the VM and re-add it, the job will run successfully again.

I'm assuming the job fails after restore because the underlying ID of the VM is different, but is this expected behavior? I would hate to have to redo backup jobs just because I had to restore a VM.

Thanks...