Comprehensive data protection for all workloads
Post Reply
Vault-Tec
Lurker
Posts: 2
Liked: never
Joined: Jun 03, 2014 7:51 am
Full Name: Vault-Tec

Veeam takes too much time to "read"

Post by Vault-Tec »

Hi everybody,

I am encounteering some issues with my backups. My company's is split into two places, and I recently moved my QNAP from one place to another. There's a VPN (20 mbits) between the two sites.

But since I moved the "target", all my VM's backup are randomly slow. For example, one virtual machine takes 24 minutes to read 1.7 Gbits, but the next one (on the same ESX) takes about 54 minutes to read... 928 mbits.

There's two ESX to backup, for approximatively 20 VMs.

Why veeam takes so much time to read this files? Its an incremental backup, btw, running at 4:00 am.

I also note that the source is "bottlenecked" at 99%. I've checked data transfer speed on the primary switch, no problems.

Here are the screenshots:

Image

http://cjoint.com/data/0FdkElCE9Kx.htm

Image

http://cjoint.com/data/0FdkFPx9PP2.htm

Thanks a lot!
foggy
Veeam Software
Posts: 21070
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Veeam takes too much time to "read"

Post by foggy »

Could you please clarify, is this QNAP NAS used to store original VMs or it is a backup target (used to store backups)?
Vault-Tec
Lurker
Posts: 2
Liked: never
Joined: Jun 03, 2014 7:51 am
Full Name: Vault-Tec

Re: Veeam takes too much time to "read"

Post by Vault-Tec »

Thanks for you answer!

It's a backup target. As I said, original VM's are stored thanks to ESX 1 and 2, QNAP is only used to store backups.
Gostev
Chief Product Officer
Posts: 31524
Liked: 6700 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Veeam takes too much time to "read"

Post by Gostev »

Hi it's not read that is taking time, but something else. Veeam is not slow to read - as the screenshots show, data was read very fast in both cases (speed is about the same in both cases). You should open a support case and have our engineers investigate the debug logs to see what is causing the duration to be so long. Perhaps some finalization process hangs in VDDK, or something like that. Thanks!
Post Reply

Who is online

Users browsing this forum: No registered users and 106 guests