very slow restore speed

[joergr]

sorry guys, i am a hardcore evaluator when it comes to spending huge ammounts of money for a huge datacenter....so here we go, more questions:

i installed veeam b+r to my windows 7 x64 machine. On that machine i located a backup done with veeam b+r. the harddisk is an intel x25e slc ssd raid0 (2 x25e´s), very very fast. Now when i restore my 85 gig machine to the harddisk (from ssd to ssd, same machine), it copies about 13gig with speed like hell (about 280mb/s) and then suddenly breaks totally down and waits for about 5 mins. no hd activity at all. then again, after about 5 mins it comes to life again and continues it´s job as supposed to be. till 100%. there it stucks again waiting forever (for about 15 mins this time, unbelievable). but i can definitely tell (procmon, taskmgr, taskexplorer) these five minutes at first and these 15 minutes at the end it did absolutely NOTHING. Neither cpu nor hd stuff. finally it finishes everything for good.

Could someone give an explanation for this behaviour?

best regards,
Joerg

[Gostev]

Joerg, I do not recall this behavior reported before, but can this be somehow related to your SSD drives and bad firmware, or I/O controllers on this computer? Do you see the same behavior on a different computer with regular drives, possibly another OS? I cannot do anything at this point but blame another vendor (hehe) because this issue is not known. But it is also fair to say that you are probably the first to test the restore speed in such conditions

If you open support case and provide full logs, our devs might be able to say more on what is going on during those "wait" periods and what component is waiting for what.

P.S. Just recalled I have seen similar behavior with some file management tools, their were "hanging" periodically and in the end of transfer waiting for Windows to commit the file system cache to disk.

[tsightler]

SSD's can cause some very strange behavior when performing large sequential writes because of the way SSD's work. They generally don't overwrite deleted files immediately but rather perform a "garbage collect" in the background. When there is very heavy write activity and you hit the threshold of free space it has to perform this "garbage collect" all at once and can cause fairly large hangs. That's just a guess, but it's worth checking, especially if you're drive has been full before. You might want to force a TRIM prior to testing the restore with Veeam.

[joergr]

thank you for the feedback, i will investigate this test by repeating it with a pc with old style harddisks

[stevenrodenburg1]

"till 100%. there it stucks again waiting forever (for about 15 mins this time, unbelievable). but i can definitely tell (procmon, taskmgr, taskexplorer) these five minutes at first and these 15 minutes at the end it did absolutely NOTHING. Neither cpu nor hd stuff. finally it finishes everything for good"

Just sharing: I see the exact same behaviour when restoring to SSD's.

I am doing a couple of "full-vm, single VMDK VM" restores at the moment. The array is a Nexenta system with HDD- and SSD-Based iSCSI-LUN's presented to the ESX Hosts (very fast connections, several 100MB/s throughput read and write, thanks to multi 1Gbps, vSphere iSCSI MPIO and LACP on the Nexenta).

The restores that go to the HDD based LUN's are fast, get to 100% and finish. Done.

The restores that go to the SSD based LUN's are fast, get to 100% and then hang...... and hang..... then finally after about 10 minutes....... they finish normally. Done.

What i see is that during SSD restores: the hangs occur after the VMDK is written 100% in our case.
With restores to HDD, one sees the next log-entry "Registering restored VM", directly after the VMDK has finished writing 100%.
Not so with restores to SSD: that log entry comes about 10 minutes later (in our environment, i can not speak for others).