Comprehensive data protection for all workloads
Post Reply
Bunce
Veteran
Posts: 259
Liked: 8 times
Joined: Sep 18, 2009 9:56 am
Full Name: Andrew
Location: Adelaide, Australia
Contact:

Full VM restore - ID retention

Post by 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
Veteran
Posts: 282
Liked: 26 times
Joined: Nov 10, 2010 6:51 pm
Full Name: Seth Bartlett
Contact:

Re: Full VM restore - ID retention

Post by 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.
Skype: Sethbartlett88 - Make sure to label who you are and why you want to add me ;)
Twitter: @sethbartlett
If my post was helpful, please like it. Sometimes twitter is quicker to hit me up if you need me.
Bunce
Veteran
Posts: 259
Liked: 8 times
Joined: Sep 18, 2009 9:56 am
Full Name: Andrew
Location: Adelaide, Australia
Contact:

Re: Full VM restore - ID retention

Post by 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.
VP, Product Management
Posts: 27368
Liked: 2798 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Full VM restore - ID retention

Post by 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
Chief Product Officer
Posts: 31793
Liked: 7295 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Full VM restore - ID retention

Post by 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
Veteran
Posts: 259
Liked: 8 times
Joined: Sep 18, 2009 9:56 am
Full Name: Andrew
Location: Adelaide, Australia
Contact:

Re: Full VM restore - ID retention

Post by 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
Chief Product Officer
Posts: 31793
Liked: 7295 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Full VM restore - ID retention

Post by 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
Influencer
Posts: 24
Liked: 2 times
Joined: Sep 21, 2009 9:30 pm
Full Name: Patrick Parks
Contact:

Re: Full VM restore - ID retention

Post by pparks1 »

Vitaliy S. wrote: 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
Chief Product Officer
Posts: 31793
Liked: 7295 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Full VM restore - ID retention

Post by Gostev »

Disk level restores support restoring thin disk as thin in v6.
mlichstein
Lurker
Posts: 1
Liked: never
Joined: Jul 18, 2011 9:06 pm

Resume backup job after restore

Post by 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...
Post Reply

Who is online

Users browsing this forum: evandrosp, Google [Bot], mjr.epicfail, Semrush [Bot] and 90 guests