1 VM is taking 3-4 Hours

[cfreeman4798]

Hello all,

I am new to this so and I have tried to research my exact issue but have had no luck. We are running a backup every night. There are 20 total servers in the backup job and it completes every night, no issue. The problem I am having is with a particular file server. There are 2 file servers in the job 1 wtih 1.9 TB of data and the other with 1.1 TB of data. The larger one, we call ARLSAN is taking 3 or 4 hours to backup. The problem is that Veeam is reading the entire 1.9TB hard drive. This is the only VM that gets the entire hard drive read and it is killing our performance. This used to not happen so I do not know where to begin.

For reference we are running Veeam 8.0.

FS1, the smaller one, only gets about 2.1 gb read. and it takes 22 minutes.

Any help would be greatly appreciated.

Thank you.

-Chase

[Vitaliy S.]

Hello,

Is CBT enabled for this VM if you drill down to the task session details?

Thank you!

[cfreeman4798]

Yes, CBT is enabled.

[edfops]

Is CBT actually being used? Have you tried resetting CBT?

[Vitaliy S.]

Do you have any maintenance tasks running in the file server? Do you have a dedupe volumes there by any chance?

[cfreeman4798]

edfops: I have not tried that but I can.

Vitaliy: There is nothing running on the FS and no dedupe volumes there.

[Vitaliy S.]

Ok, so as a first step of troubleshooting, let's make sure CBT is indeed leveraged. Can you please post stats from a couple of sessions with Read/Transferred/Processed counters, cause based on what you say it is not used or not enabled?

[cfreeman4798]

We actually solved the problem I believe. Our file server was being overloaded because it's older and only had 3gb of ram, we slapped 16 in it and it seems to have solved the issue. will know more once a backup completes.

[Vitaliy S.]

Well... VM configuration cannot affect the number of changed blocks, so it seems like the CBT data is now properly leveraged.

[dellock6]

Well, a possible cause could be, reading the potential solution, the system had too low memory and because of this it was swapping to disk, increasing the IO of the VM itself...