Slow vm restore v3.1

That problem was resolved, we changed the dd command from using the option bs= to using the options ibs= and obs=. bs is supposed to set the input and output block size but it does not always set both by design. So that is not your problem.

You need to find your bottleneck. It is either a CPU or IO problem. While doing a backup or restore is there a process using nearly 100% CPU? The utilities top or my favorite htop will display the information needed to answer the question.

Do you have other processes performing disk IO while you are backing up or restoring? Use iotop to look at that.

What is your storage? Single disk, raid array, etc?

System specs like CPU model, RAM etc would also be helpful.

The backup process is improved in the next version of Proxmox with KVM 1.7 but it mostly fixes VM IO performance, not backup*performance, while performing backups.
 
hi there, sorry for late reply. we have a cluster from 3 IBM servers - each X3650 - Xeon E5-2650 v2- Ram 64GB, 4 Gigabit Ethernet, bonded in one bridge port. the storage is Qnap TS-879U-RP - 4GB RAM - 8 x 3,5" x 2TB/HDD - 2 Gigabit Ethernet - link aggregation The servers and storage are linked in 2 redundant Cisco Gigabit switches. thank you
 
Hi there,

Tested again last night. The restore was made in 8,5 hours....Very slow...
2s11xqp.png
Anyone any suggestion? the upgrade to 3.2 would help in any direction?

Thank you
 
I had no time for make tests, but it seems a QNAP NFS problem.
I have the similiar behaviour with a ts-859u-rp+

Can you place a test setting up an nfs share (on a real server) and try a backup?
 
You must log in or register to reply here.
Top Bottom