v6 initial incremental massive

[Davd]

I recieved a new Veeam.Backup.Core.dll from Veeam support with instruction to replace the one that is in Veeam folder. After that I launched 2 backup jobs and both worked fine. VIB files are now "normal" size again and the backup speed is as expected. So it looks like R&D found a solution.

Thanks Veeam for addressing the issue and providing a solution that quickly

[Gostev]

David - I thought our support asked you not to post about this on the forum just yet and there was a good reason for that - the current DLL was not built with the "release" configuration, so we would still need to go through the normal build process and test the final DLL before we can start distributing it to everyone who has the support cases open.

Good to hear that it helps though!

[Davd]

sorry...my misstake. I totally missed that part in the email...

I was so focused on the solution part of the email that I didn notice just that

[aaron_228]

At least it's a known problem and people don't think it's just them now

[Gostev]

There is sticky topic posted on this forum that I posted earlier today, it lists all known v6 issues including this one... people just need to read stickies

[aaron_228]

There is sticky topic posted on this forum that I posted earlier today, it lists all known v6 issues including this one... people just need to read stickies

Oops, I guess i'm kinda just trained to skip past those from other forums.

Do you guys need more technical cases/logs of the SAN fail over to NDB thing? I'm having it as well, but if it's already known I'm not sure if I should bother?

[Gostev]

Aaron, logs definitely would not hurt - last time I checked with R&D few hours ago, the research was still "in process". We would also love to have a list of customers available in support who are ready to validate the fix (we could not reproduce this issue on our own SAN storage devices), so if you open the support case, our support will track you for that purpose as well. Thanks for your willingness to help!

[jbeunel]

[merged]

Hello

I just upgrade my veeam V5 to veeam backup V6 and i have a problem.
My job run using network mode , i use the last build of vmware ESXi 4.1, my network speed is 1Gb/s.
With version V5 i was able to run my jobs at 700MB 800MB/s and most of my backup finish in 2 or 3 minutes.
With version V6 i run only one job on my veeam backup server and the speed is 30MB - 50MB max and it take 1hour.
I don't understand what's happend.The cpu is use at 20% , the ram is ok and i notice that the network is now use at the maximum(looks better than V5), the current speed of used bandwidth 850Mb/s for a 1Gb/s network.(With V5 it use only 300Ms/s but it's was 20X faster than V6)

Architecture:
SITE A-------1Gb/s----------------SITE B
VM1 Veem backup backuping VM1

Is there new setings to do with V6 or new architecture?
Can you help please?
With this speed all my backup will crash tonight.


Regards

[Gostev]

Jerome, you are seeing full backup here. Your next incremental run should be "normal", and much faster than in v5. See above for more details. Thanks.

[averylarry]

It does seem like a synthetic roll-up gets it back to a single large .vbk with normal sized .vrb files.

Unfortunately, I messed up one of my entire backup chains trying to work on it myself while waiting for tech support to call back.

Dunno what to do with "12/2/2011 4:27:20 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: [32176204]."

[srebucci]

Hi, as I could read from the post "[BEFORE YOU UPGRADE] Summary of known v6 issues " the patch to fix my problem is ready. I've asked the support for it (case 5158319) but they say it isn't ready yet. So where's the truth? Without it I cannot upgrade and I need v. 6 to start the Disaster Recovery project using the enhanced replication features that I'm waiting since v5 release.

[Gostev]

Patch was ready, but I am guessing coffee for our support was not

[srebucci]

Hi Gostev,
the support just send me the FTP for the patch. This afternoon will be dedicated to install and test the new release. As soon I'll get news results, I will share them with the community.

[srebucci]

After the upgrade, it works like a charm!

Thank you for the support!

[LCMMusil]

Do these massive incremental backup issues apply for reverse-incremental backups as well? (Issue #3 on the BEFORE-YOU-UPGRADE Summary) I asked support about this today, and they seemed to think that reverse incremental backups would not be affected after the upgrade to 6 from 5.02.

[Vitaliy S.]

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]

Thank you for the clarification.

[averylarry]

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]

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]

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]

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]

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]

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]

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]

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]

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.]

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]

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.]

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]

Or better yet, upgrade to the latest product version