Slow Transformation after upgrade to R2

[athome]

Hi!

I've applied R2-patch an B&R 7 Environment this week, and the copy jobs that copies the backup from local disk on the backupserver and over to a Data Domain 2500 for archiving purposes is running a transformation job that takes a really long time.

Normaly the copy jobs runs for 2-3 hours.. but after the upgrade it runs a transformation job (and it runs two jobs at the same time.. so even though I see network is running at bout 135 MB/s it is taking alot of time) it has been runing for 34 hours now and is at 92%. And now it seems like it is not going to run today. only 4 hours until the new backup is starting.

Does it do anything special with the copyjobs after the R2-patch?

Seems like it would be smart to hold back on enabling the copy jobs after the R2-patch. and enable them one at the time.. so they dont all start at the same time.

I've created a ticket: Case # 00486894

A

[Dima P.]

Anders,

Could you, please, confirm that you installed the latest Veeam v7 R2A update? Thank you.

[athome]

Hi

NO, that R2a must have been released just after I applied the patch. I have build number: 7.0.0.764.

Is there anything in the R2a that should fix what I'm seeing? I thought the R2a was just to fix some installation-issues.

[Gostev]

You are right - all differences between R2 and R2a are clearly documented, so I too have no idea why Dmitry is asking this.

Anyway, specifically to your issue, you can be sure that this is not connected to the R2 update, but rather a coincidence. We do not make changes to the engine in minor updates, and there was no bug fix around the data processing logic. Besides, if this was truly the case, other users would have reported this at least a few hundreds of times by now, as it usually happens with real bugs at least a few pages long topic on the very first day of the update availability.

As far as what can be causing this, putting possible hardware issues aside... for example, this can be due to large changes in the environment resulting in much large incremental backups than normally, which directly impacts transform time. Since the debug logs have backup file sizes for both the current and previous (faster) runs, as well as the time each transformation task took, it will be very easy to confirm if this is the case.