Poor Performance (SOLVED)

[inlineict]

I'm evaluating Veeam Backup and Replication 4.1.

Our situation:
- 1x HP MSA2324 Fibre Channel SAN
- 2x HP Proliant ML370 G5 with 8Gb Fibre HBA for virtual machines
- 1x HP Proliant ML370 G3 with Backup Exec for backup-to-disk-to-tape backup (LAN connected; no Fibre HBA)
- VMware ESXi 4 with the latest firmware available
- VMware ESXi 4 is managed by vCenter
- Gigabit network

I've installed Veeam in a virtual Windows Server 2008 x64 (1x vCPU/2GB mem/20GB disk) environment and added our vCenter,
This virtual Veeam server has a network connection to our physical Backup Exec server (X:\ drive) for placing the virtual machines backups.

When I configure a default "VM Copy Job" the copy-speed is very poor (max. 4MB/s).
Also I'm expiriencing a lot of CPU stress (100%) from VeeamAgent.exe when the backup is running.
I tried to change the Job setting to Virtual Appliance but did'nt solve the issue.

Which settings has to be made for a proper configuration of Veeam?

Kind regards.

[Gostev]

In your case, clearly CPU power is the main performance bottleneck. We recommend that customers give Veeam Backup VM 4 vCPUs, and yes, for Veeam Backup running in VM it is best is to use Virtual Appliance mode for the best performance.

Also, I highly recommend that you use Backup jobs instead of VM Copy jobs, this will give you much better performance both during full, and especially incremental, runs. VM Copy jobs are not really designed for high performance backup, they aim other use cases.

Thanks!

[inlineict]

In your case, clearly CPU power is the main performance bottleneck. We recommend that customers give Veeam Backup VM 4 vCPUs, and yes, for Veeam Backup running in VM it is best is to use Virtual Appliance mode for the best performance.

Also, I highly recommend that you use Backup jobs instead of VM Copy jobs, this will give you much better performance both during full, and especially incremental, runs. VM Copy jobs are not really designed for high performance backup, they aim other use cases.

Thanks!

Dear Gostev,

After changing this setting (4 vCPU's) it solves the issue! The backup speed is now between 35 - 90 MB/s!
Only when the backup is finished I get a error message:
RemoveSnapshot failed, snapshotRef "snapshot-105", timeout "3600000"
Unable to access file <unspecified filename> since it is locked.

Is this solved after the next backup run or did I have to manually remove the snapshot?

[Vitaliy S.]

Jan-Willem, yes this snapshot will be removed on your next job run, but you may consider removing it manually using Vmware Infrastructure Client.

[Gostev]

RemoveSnapshot failed, snapshotRef "snapshot-105", timeout "3600000"
Unable to access file <unspecified filename> since it is locked.

This is not a typical or expected issue, and should never happen under normal circumstances. Looks like something else is holding the snapshot file. Do you have this issue only on one, or with multiple VMs?

[TrevorBell]

I had this issue on a VM today, in my case it happens when i quit a backup half way through ( i know i bring on this error myself ) how i solve it is to shutdown the vm, then clone it and power it on ( then delete the original vm )

Works for me as the Vm in question is just a VM Ghost server and not nothign mission critical

hope that helps.

Trev

[glennsantacruz]

We have also seen similar behavior to what you're describing, although we have not yet been able to completely reproduce it in a lab-style setting. Basically, if Veeam ( we run ours as a VM -- in Appliance Mode ) hiccups ( or we manually stop a job ), there have been occasions where Veeam will not release the hot-added SCSI drives of the VM which was being backed up (call it "VM-to-backup"). Subsequent attempts to remove snapshots on VM-to-backup (via vCenter) would also fail, claiming the same error of "Unable to access file <unspecified filename>..."

Our solution was to shut down the Veeam VM, then manually remove any SCSI devices that were *not* owned by Veeam, followed by a power-on of Veeam. We could then successfully remove the VM-to-backup snapshots.