hello, we ha 2 vm on our Esxi Host.
Source hard disk VM is Raid 10 (tested speed raid 300mb/s RW)
Destination another hard disk on mainboard (Seagate 1 TB 120 Mb R/W Tested with copy with bash esxi)
(Id)VM Name State Size (Gb) Stop Copy Start Time (min:sec) Speed (mb/s)
(13) T310.stu****.it ON 570.00/ 570.00 NO (hot backup) OK - 377:41 25/ 25
(16) Windows_DC2 ON 40.00/ 40.00 NO (hot backup) OK - 08:27 80/ 80
What can this difference depend on?
I analyzed the situation for days, there is no machine load or other threads or anything else.
raid the same
destination the same.
speed really different
Last edited by AlessioCalvio (2020-07-20 10:08:42)
That speed that you see there is an average, it includes the time it takes to do some basic checks and to take and delete snapshots. It's true that it's not spectacular to put it that way. You should take on account when and how you performed the speed tests previous to the backup: was the server iddle? are there some VM running now that you are performing backups?
Your disks seem to be thick, this may add some extra time. You don't say what backup program/method you are using, this can also affect the effective speed.
When it comes to backup disks between local storage, the fact that will affect the most is how fragmented the disks are, both from a guest perspective and from the VMFS point of view. It's not the same to have a few extents of data in a virtual disk than thousands of them. That is: it's not the same jumping over a 1GB zeroed zone than having to detect one thousand 1MB zeroed extents.
Run this command:
vmkfstools -t0 /path/to/your/disk.vmdk
And check what is the number of reported extents. It should not exceed a few hundred in case of your smaller VM or a few thousand in case of the bigger one.
In case you observe a lot of small chunks of data scattered across the virtual disk, do the fllowing:
- Make sure that the guest OS is defragmented. You don't generally have to worry about that on Linux journaled systems, but you may have to program some defragmentation schedule on Windows systems, especially if they are fragmented above 5%
- Clone the virtual disks to thin format, unless you have some very good reason to keep them thick and you know exactly why they should remain thick. This will compact extents to a lower number and make data be stored in bigger extents.
On top of the above. The way the physical layer is aligned to the logical storage layers can affect performance A LOT.
Run this command:
esxcli storage core device partition list
Check where do your storage partitions start in each disk. They should start at 2048 if the disks have been partitioned with a relatively new ESXi system. If they are not aligned to this sector number, then the hardware storage may be misaligned and this may cause an extra load on the hardware that is by no means negligible.
This post explains the issue in a very graphical and visually explicit way.
Virtual disk alignment