Host-based backup of VMware vSphere VMs.
Post Reply
Zew
Veteran
Posts: 365
Liked: 80 times
Joined: Mar 17, 2015 9:50 pm
Full Name: Aemilianus Kehler
Contact:

Restore VM without breaking backup chain

Post by Zew »

I generally do an instant recovery if I need to recover a VM to ensure the things stay running. I know I talked about this before but I figure I'd bring it up again cause again its one huge pet peeve.

When I recover a VM using instant VM recovery, Veeam fails to see this VM as the VM its backing up (From the very job I recovered it from).

So now this backup job fails until I point it to this VM with the same name and everything. to top it off my backup copy job then has to transfer a huge amount of data. Which has you could guess is a low bandwidth connection.

Am I forced to recover with a different method to keep my chains in tact?
foggy
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Restore VM without breaking backup chain

Post by foggy »

Instantly recovered VM is a completely new VM from Veeam B&R's viewpoint. It is registered in virtual infrastructure with its own unique ID, so you need to add it in the backup job to back it up and the first run will back it up in its entirety. If you're using WAN acceleration within backup copy job, similar blocks will not be re-transferred.
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Restore VM without breaking backup chain

Post by Vitaliy S. »

A workaround for this behavior would be to use VM containers (resource pools, VM folders, tags etc) as a source for the backup job. In this case when you recover the VM and register it in the given container, the backup job will be able to automatically pick it up. Hope this helps!
DaveWatkins
Veteran
Posts: 370
Liked: 97 times
Joined: Dec 13, 2015 11:33 pm
Contact:

Re: Restore VM without breaking backup chain

Post by DaveWatkins »

I don't think it's surprising why a new chain is created. It's more about the fact that from a technical standpoint there is no reason to do it. Yes the VM has a new ID, but there isn't a technical reason a new full backup needs to be created. Veeam already knows the exact VM state. In fact there doesn't seem to be a technical reason why CBT couldn't be used to create the next incremental. It seems like Veeam should be able to remap/translate the ID of the new VM back tot the old until the old backups fall out of retention, and re-base the chain so the restore point used becomes the base (eventually) and this new secondary chain is the live one.

Obviously we're into "feature request" territory here but from a technical standpoint it seems feasible. Also unless you have a fairly deep knowledge of the product, I'd argue it's not the expected behavior either
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Restore VM without breaking backup chain

Post by Vitaliy S. »

Hi Dave,

Thanks for your input.
DaveWatkins wrote:Yes the VM has a new ID, but there isn't a technical reason a new full backup needs to be created
Actually, this is a technical reason (VM ID change) for the new backup to be created. If we are talking from a user perspective, you're absolutely correct, you don't want to create a new full backup.
DaveWatkins wrote: In fact there doesn't seem to be a technical reason why CBT couldn't be used to create the next incremental.
The technical reason is simple, there is no CBT ID for the restored VM. Let me explain this further - every job is tracking CBT USN for every VM, so when VM is restored this CBT data is reset by VMware, which makes querying CBT data operation (based on the USN) impossible. There is no data to compare, thus a full VM scan is required.
DaveWatkins wrote:It seems like Veeam should be able to remap/translate the ID of the new VM back tot the old until the old backups fall out of retention, and re-base the chain so the restore point used becomes the base (eventually) and this new secondary chain is the live one.
Yes, we do provide assistance in these cases when people restore VMs and cannot run a new full backup due to lack of free space. See this topic for more information > Moving VMs to a new virtual center.

Thanks!
DaveWatkins
Veteran
Posts: 370
Liked: 97 times
Joined: Dec 13, 2015 11:33 pm
Contact:

Re: Restore VM without breaking backup chain

Post by DaveWatkins »

Hi Vitaliy

I was thinking more about restoring the CBT state when the VM is restored originally, but that's probably not actually backed up. Even without CBT though the first new backup should be able to be a standard incremental without CBT if there was some translation between the old VM ID and the now new one. By translation I'm not talking about manually remappping it. I'm talking about Veeam being aware of this internally. For example when you restore the new VM then there is a DB entry saying, from this restore onwards the backup chain is split (if you didn't restore from the latest restore point) and from this restore point onwards the VM ID of this VM is now "xxxx".

I would argue that's what the end user expects to happen. Veeam should be able to manage the new VM ID since it's the creator of the new VM, so certainly has access to the new ID during that initial restore.

Dave
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Restore VM without breaking backup chain

Post by Vitaliy S. »

Unfortunately, you cannot restore CBT state as it is controlled solely by VMware.
DaveWatkins wrote: Even without CBT though the first new backup should be able to be a standard incremental without CBT if there was some translation between the old VM ID and the now new one.
This is exactly what Veeam is doing when source VM CBT data is corrupt, lost or not readable. Here is one of the existing topics for more info > Resetting CBT / Necessary if running active full?
DaveWatkins
Veteran
Posts: 370
Liked: 97 times
Joined: Dec 13, 2015 11:33 pm
Contact:

Re: Restore VM without breaking backup chain

Post by DaveWatkins »

But it doesn't in this case, as the new VM isn't considered part of the old chain. The feature we're discussing, that doesn't currently exist is for Instant Recovered VM's to continue using their old backup chain after they are restored. All I'm suggesting is feasible ways that could be made possible automatically by Veeam. I know it's a feature request, and that's fine :)
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Restore VM without breaking backup chain

Post by Vitaliy S. »

Yes, and I'm not saying it is not valid, it does make sense. Just trying to explain technical reasons why it is not implemented yet, as per you original post ;)
DaveWatkins
Veteran
Posts: 370
Liked: 97 times
Joined: Dec 13, 2015 11:33 pm
Contact:

Re: Restore VM without breaking backup chain

Post by DaveWatkins »

I didn't start the thread :) I knew the reason already so that explains the confusion. Just wanted to point out the possibility of an area that could be improved
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Restore VM without breaking backup chain

Post by Vitaliy S. »

Yes, I know you didn't start a thread. Seems like we are on the same page now.
Zew
Veteran
Posts: 365
Liked: 80 times
Joined: Mar 17, 2015 9:50 pm
Full Name: Aemilianus Kehler
Contact:

Re: Restore VM without breaking backup chain

Post by Zew »

Dave,

That's exactly what I'd like as a feature too! Basically if you are restoring a VM using instant recovery (basically you are already hooped so bad your old VM is garbage and let's say you straight up removed it it, deleted it from vCenter) and you go to recover doing an instant recovery, then migrating it to production.

It would be nice to have an option to tell Veeam that you are planning to use this has your new server for that server/chain.

I totally get you guys under why it was happening, as I mentioned I have come across this before. But I think for (instant recovery) to be a true feasible recovery option, keeping an existing chain intact should be part of it.
lando_uk
Veteran
Posts: 371
Liked: 32 times
Joined: Oct 17, 2013 10:02 am
Full Name: Mark
Location: UK
Contact:

Re: Restore VM without breaking backup chain

Post by lando_uk »

Just to add to this, the newly restored VM wont actually use anymore repository disk space even after a full backup and new chain, as it get's deduplicated against the original VM.
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Restore VM without breaking backup chain

Post by Vitaliy S. »

Yes, but that's true for reversed incremental backup mode only.
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Restore VM without breaking backup chain

Post by pkelly_sts »

Out of interest, would it make any difference to things if, instead of "full VM restore" we use a "restore vm hard disks" which retained the original shell VM/ID?

Also, talking about CBT resets etc. I thought that simply caused the original backup to be *re-read* rather than force an active full, so can't such a restore just initiate a full re-read of CBT-related data (or whatever the official task is)?
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Restore VM without breaking backup chain

Post by Vitaliy S. »

pkelly_sts wrote:Out of interest, would it make any difference to things if, instead of "full VM restore" we use a "restore vm hard disks" which retained the original shell VM/ID?
When you restore virtual disks, their CBT data will be reset, which will initiate a full data re-read for this VM.
pkelly_sts wrote:Also, talking about CBT resets etc. I thought that simply caused the original backup to be *re-read* rather than force an active full, so can't such a restore just initiate a full re-read of CBT-related data (or whatever the official task is)?
That is the case with VM replicas, where you can map VM to a VM image, but in case of backup jobs you do not select a particular VM in the backup file that can be used for mapping.
pkelly_sts
Veteran
Posts: 600
Liked: 66 times
Joined: Jun 13, 2013 10:08 am
Full Name: Paul Kelly
Contact:

Re: Restore VM without breaking backup chain

Post by pkelly_sts »

That was what i meant - the data re-read which is only a read, not a full re-copy is it not?

In other words, if for whatever reason we lose/reset CBT data, it only causes the original disk to be fully read, to understand its current situation etc., as opposed to fully copied to destination?
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Restore VM without breaking backup chain

Post by Vitaliy S. »

Yes, if VM ID is retained and CBT data is lost/corrupt/etc. backup job will re-read the entire image and then transfer only changed blocks (our propriety change tracking engine), though I need to double-check if it is true for restored virtual disks with new IDs.
Zew
Veteran
Posts: 365
Liked: 80 times
Joined: Mar 17, 2015 9:50 pm
Full Name: Aemilianus Kehler
Contact:

Re: Restore VM without breaking backup chain

Post by Zew »

Thanks for the additional info guys. Glad to see the interest this topic has spun.
Post Reply

Who is online

Users browsing this forum: ekulaga and 85 guests