Veeam v6.1 - first incremental backup after a synthetic full

[g4v1n]

Hi all,

I tried googling and searching the forum but haven't been able to find an answer for this. I also haven't raised this with support as I am not sure if it's an error. Just asking the question as to why it might happen really

The situation is we have a client who runs Backup & Replication v6.1. He has 1 backup job that contains 6 vmware virtual machines. The backup runs @ 21:30 Mon - Fri and uses Incremental as the backup mode with Synthetic fulls on a Saturday and the transform previous full backup chains into rollbacks option is checked.

There is also a replication job which covers the same 6 vm's and runs everyday @ 6pm

So nothing too complicated so far. However what I have witnessed is that the first incremental which runs after the Synthetic Full, so this would be Monday night takes significantly longer and the processing rate is also a lot less than when a subsequent incremental runs.

Generally our incrementals are getting between 500 MB/s - 2GB's as the processing rate for the job and usually take between 30mins - 2 hrs

This monday night job though seems to take anywhere between 15 - 19 hrs and the processing rate drops to between 40 - 50 MB/s. I have checked back over the past weeks and this is consistent behaviour

So just a question really - Is that normal and why would the first incremental after the synthetic full take so long?

[foggy]

What about the amount of data processed/transferred during these first increment passes? Is it the same as usual?

[Vitaliy S.]

Out of curiosity, can you please open the latest job session and check what VM takes most of the processing time?

[g4v1n]

looking over the last 2 weeks starting on Mon 8th the details for the Mon - Fri incrementals is as follows:-

Mon 8/4/13 = Processed = 2.6tb, Read = 2.4tb, Transferred = 4.3Gb - processing rate =46MB/s, duration = 16:35:30
Tues 9/4/13 = Processed = 3.1tb, Read = 7.6gb, Transferred = 1.9Gb - processing rate =2GB/s, duration = 0:24:49
Weds 10/4/13 = Processed = 3.1tb, Read = 12gb, Transferred = 4.1Gb - processing rate =2GB/s, duration = 0:33:15
Thurs 114/13 = Processed = 3.1tb, Read = 12.2gb, Transferred = 3.6Gb - processing rate =2GB/s, duration = 0:33:22
Fri 12/4/13 = Processed = 3.1tb, Read = 8.8gb, Transferred = 2.3Gb - processing rate =2GB/s, duration = 0:30:56

Sat 13/4/13 = Processed = 3.1tb, Read = 7.2gb, Transferred = 2.0Gb - processing rate =456MB/s, duration = 1:57:02 - this should be the synthetic full with transform rollback

Mon 15/4/13 = Processed = 2.6tb, Read = 2.4tb, Transferred = 14.3Gb - processing rate =48MB/s, duration = 15:54:57
Tues 16/4/13 = Processed = 3.1tb, Read = 29.8gb, Transferred = 15.6Gb - processing rate =1GB/s, duration = 0:51:47

As you can see our Monday incremental takes a lot longer to run and for reason reads a lot more data (2.4tb) than the incrementals that run on Tues - Fri

Any ideas?

[g4v1n]

The vm's that take the longest are always the same 2. One is a file server and the other is designated as a print server but also acts as a secondary file server for non-user data as well.

[Gostev]

Some sort of defrag or script scheduled prior to Monday backup perhaps... something that makes lots of changes to file systems of those 2 VMs.

[foggy]

Or CBT data is reset for some reason and Veeam B&R has to re-read full VM images.

[g4v1n]

thanks for the replies guys. I will see if there is anything else happening. So it's safe to say then that this is not normal expected behaviour?

A couple of other quick questions for you... what would cause the CBT data to be reset? Would the replication job that runs on the Sunday cause this? Should I uncheck Sunday from the schedule as there is no real need to run it on that day?

We did have some issues in the past when backups were taking a long time due to the "Cannot use CBT: Soap Fault" issue. I reset the CBT as per the info in your knowledge base article KB1113, and since doing that the backups have been stable apart from this Monday night incremental issue. The monday job runs successfully with no warnings/errors it just takes longer.

cheers

[foggy]

So it's safe to say then that this is not normal expected behaviour?

Yes.

A couple of other quick questions for you... what would cause the CBT data to be reset? Would the replication job that runs on the Sunday cause this? Should I uncheck Sunday from the schedule as there is no real need to run it on that day?

Replication should not affect CBT. Could be host or storage issues, for example. You could open a support case and have our engineers investigate the job logs for possible reason. Please include the support case ID here for future reference. Thanks!

[g4v1n]

ok thanks for the info guys

just awaiting info back from the client regarding scheduled jobs/defrags etc before I open a support case.

I did have a thought about whether it might be related to Anti-Virus scheduled scans so waiting on an answer for that also.