Comprehensive data protection for all workloads
Vitaliy S.
Product Manager
Posts: 22278
Liked: 1410 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: v6 initial incremental massive

Post by Vitaliy S. » Dec 15, 2011 8:32 am

Hi Michael, jobs with reversed incremental backup mode are not affected by this. This issue specifically talks about VIB files which are only created while using forward incremental backup mode. Thanks!

LCMMusil
Lurker
Posts: 2
Liked: never
Joined: May 11, 2011 4:40 pm
Full Name: Michael Musil
Contact:

Re: v6 initial incremental massive

Post by LCMMusil » Dec 15, 2011 2:43 pm

Thank you for the clarification.

averylarry
Expert
Posts: 261
Liked: 28 times
Joined: Mar 22, 2011 7:43 pm
Full Name: Ted
Contact:

Re: v6 initial incremental massive

Post by averylarry » Dec 19, 2011 7:24 pm

I didn't apply this patch because I couldn't wait for the patch and just started completely over.

However -- today it's doing it again, on 2 different jobs. 1 job is a brand new job created in v6. The other job is one that I was able to continue from v5.

I'll apply the patch today and see what happens.

averylarry
Expert
Posts: 261
Liked: 28 times
Joined: Mar 22, 2011 7:43 pm
Full Name: Ted
Contact:

Re: v6 initial incremental massive

Post by averylarry » Dec 19, 2011 8:25 pm

If a virtual disk is moved to a different datastore, will it have to do a full backup on that disk?

After the patch, one of the drives (that was moved to a different datastore) STILL did a full backup, but the other drives did incremental (and they were doing full earlier). I haven't tested the other job yet.

Gostev
SVP, Product Management
Posts: 24014
Liked: 3250 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: v6 initial incremental massive

Post by Gostev » Dec 19, 2011 8:44 pm

Out of common sense, there is no way for us to match "new" disk to the "old" disk in backup (same name and size is not enough to make that conclusion) - which is why full backup is required. I will confirm my response with the devs tomorrow.

Also, make sure you are not mapping backup file created by one Veeam deployment into another one, as this would cause full backup as well instead of incremental. Backup file mapping is only supported within the same deployment.

averylarry
Expert
Posts: 261
Liked: 28 times
Joined: Mar 22, 2011 7:43 pm
Full Name: Ted
Contact:

Re: v6 initial incremental massive

Post by averylarry » Dec 19, 2011 8:55 pm

Well -- I used VMware migration to move a virtual disk from one datastore to another. (Not the entire VM, and I don't have storage vMotion.) I guess I would understand if CBT wasn't maintained -- but I certainly don't think for a moment that CBT couldn't be maintained -- but that would be for VMware, not Veeam, to maintain. No backup file mapping or anything like that happening here.

Gostev
SVP, Product Management
Posts: 24014
Liked: 3250 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: v6 initial incremental massive

Post by Gostev » Dec 19, 2011 9:02 pm

Well, it's completely NOT about CBT - there is just no way for the job to understand that this is the same virtual disk. Only you know that it was migrated, but the job sees that as plugging in some new virtual disk from another datastore to the VM - with certain size and certain name. To make it even more complicated, VMware even supports VM having different virtual disks with the same name - as long as they are on different datastores. So you can have 2 virtual disks with absolutely different content, but the same name and the same size (just on different datastores).

averylarry
Expert
Posts: 261
Liked: 28 times
Joined: Mar 22, 2011 7:43 pm
Full Name: Ted
Contact:

Re: v6 initial incremental massive

Post by averylarry » Dec 20, 2011 5:05 pm

That seems counter-intuitive. I didn't edit the VM configuration to remove the disk, then manually move the .vmdk files, and edit the VM configuration to add it back in. So VMware clearly knows that it's the "same" virtual disk.

So what happens when someone uses storage vMotion to move a disk to another datastore? Does Veeam always start over with a full backup?

Gostev
SVP, Product Management
Posts: 24014
Liked: 3250 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: v6 initial incremental massive

Post by Gostev » Dec 20, 2011 7:43 pm

Well, Storage VMotion does not touch virtual disk configuration the way you did, so that's different story. You said you added the disk back as a new disk. How can the job know if you attached the same disk, or some other disk with the same name and size from a different datastore? I am going to need to ask QC to repeat your process though, to make sure I am right with my thinking.

By the way, when moving the virtual disk to another datastore, did you also move the corresponding CTK file along? As this may also explain why full scan is performed.

averylarry
Expert
Posts: 261
Liked: 28 times
Joined: Mar 22, 2011 7:43 pm
Full Name: Ted
Contact:

Re: v6 initial incremental massive

Post by averylarry » Dec 21, 2011 4:01 pm

Sorry -- I didn't say I manually moved it (I said "didn't"). I wasn't clear at first, but I used VMware migration. You know -- you shut down the virtual machine, right click on it and select "Migrate". Then you do an advanced migration where you only migrate certain disks to different datastores. I supposed I'd call it the equivalent of "cold storage vMotion". I have VMware Essentials Plus which means no "hot" storage vMotion. So VMware (vCenter) did it -- not through datastore browser or Veeam copy or scopy or anything else.

meeyou
Influencer
Posts: 22
Liked: never
Joined: Oct 16, 2012 5:47 pm
Full Name: John White
Contact:

Re: v6 initial incremental massive

Post by meeyou » Dec 17, 2012 5:50 pm

Is this replacement DLL still being distributed only as needed or is there an update I can apply for this issue?

I've got a forever-incremental w/ synthetic fulls and rollbacks that runs fine except on synthetic day, where it completes the backup fine then fails with this error.

Code: Select all

12/15/2012 8:19:11 PM :: TextFromTar failed
Client error: There is no FIB [summary.xml] in the specified restore point.
Failed to restore file from local backup. VFS link: [summary.xml]. Target file: [MemFs://Tar2Text]. CHMOD mask: [0].

Vitaliy S.
Product Manager
Posts: 22278
Liked: 1410 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: v6 initial incremental massive

Post by Vitaliy S. » Dec 17, 2012 7:43 pm

Hi John,

Thanks for using search! But this is a one year old thread, so I believe this issue should have already been resolved by the newer versions of Veeam B&R. Can you please tell me what version are you at? What is your support case number?

Thanks!

meeyou
Influencer
Posts: 22
Liked: never
Joined: Oct 16, 2012 5:47 pm
Full Name: John White
Contact:

Re: v6 initial incremental massive

Post by meeyou » Dec 17, 2012 8:00 pm

Vitaliy S. wrote:Hi John,

Thanks for using search! But this is a one year old thread, so I believe this issue should have already been resolved by the newer versions of Veeam B&R. Can you please tell me what version are you at? What is your support case number?

Thanks!
Hi Vitaliy, sorry to necro this old thread, I neglected to read the year in the date stamp.

I haven't opened a support case yet as I just encountered this issue. The Veeam version is 6.1.0.181 64-bit.

Vitaliy S.
Product Manager
Posts: 22278
Liked: 1410 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: v6 initial incremental massive

Post by Vitaliy S. » Dec 17, 2012 8:33 pm

Could you please try to apply this patch that should resolve your issue? See this KB article for the download link: http://www.veeam.com/KB1671

Gostev
SVP, Product Management
Posts: 24014
Liked: 3250 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: v6 initial incremental massive

Post by Gostev » Dec 17, 2012 9:09 pm

Or better yet, upgrade to the latest product version ;)

Post Reply

Who is online

Users browsing this forum: Paul.Loewenkamp and 41 guests