Host-based backup of VMware vSphere VMs.
chjones
Expert
Posts: 117
Liked: 31 times
Joined: Oct 30, 2012 7:53 pm
Full Name: Chris Jones
Contact:

Re: Incredibly slow Direc SAN restore

Post by chjones » 2 people like this post

I just did a test restore from Veeam v8 and had this ongoing restore speed issue when using the SAN restore mode.

I then did the exact same restore using the RTM Build of Veeam v9, also using SAN mode, and found that the restore which was maxing at maybe 70MB/sec in v8 ran at over 200MB/sec in v9. I need to do some more testing but this is a great sign. I hadn't run the vmkfstools command to zero the VMware Datastore which typically made the first restore in v8 go fast, so this is even better. Here are some points I did notice:

1. The Veeam Proxy mounts the SAN Volumes as Offline in Disk Management. The restore would failover to Network mode. I had to manually bring the disks on Online (but not initialize) for the restore to use SAN. I keep reading this shouldn't have to be done manually but has always been the case in my experience with every version of Veeam)

2. The source VM is Thick Eager Zeroed (as is best practice as we use HP 3PAR Storage). In v8 the restore would be Thick Lazy Zeroed. In v9 you still don't get a choice to select Thick Eager as a disk type in the restore wizard, but keeping "Same as source" selected resulted in a Thick Eager Zeroed VM that was restored.

3. I am speculating, but I believe the Thick Eager restore is the reason for the increased speed. When you restore to a new VM, Veeam first creates a new VM and then takes a snapshot, and then restores over the top of the VMDKs. Since the new VM that was created is Thick Eager all blocks on the storage are zeroed out by ESXi when the VM is created, so the restore doesn't have to check each block when restoring to ensure that block is free to write to, which is what was causing the slow restores in v8.

So far so good with the testing of Veeam v9 and SAN Restore Speeds.
Delo123
Veteran
Posts: 361
Liked: 109 times
Joined: Dec 28, 2012 5:20 pm
Full Name: Guido Meijers
Contact:

Re: Incredibly slow Direc SAN restore

Post by Delo123 »

Very cool, will also posts some results as soon as I can get my hands on V9...
Source and repository are both flash so I hope we can also get some good restore speeds finally...
foggy
Veeam Software
Posts: 21139
Liked: 2141 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Incredibly slow Direc SAN restore

Post by foggy »

chjones wrote:1. The Veeam Proxy mounts the SAN Volumes as Offline in Disk Management. The restore would failover to Network mode. I had to manually bring the disks on Online (but not initialize) for the restore to use SAN. I keep reading this shouldn't have to be done manually but has always been the case in my experience with every version of Veeam)
This is expected, since Veeam B&R automatically sets SAN policy to offline mode during installation of the proxy server.
Delo123
Veteran
Posts: 361
Liked: 109 times
Joined: Dec 28, 2012 5:20 pm
Full Name: Guido Meijers
Contact:

Re: Incredibly slow Direc SAN restore

Post by Delo123 » 1 person likes this post

Foggy, I think we all know it is expected behavior for the disks to be put to offline mode, however I also had a few cases where veeam support insisted the disks should be become active / online during a direct san restore automatically and since this was not happening it would be something in our setup. Anyway, until now I always had to do it by hand when using a new lun for direct san restores.
foggy
Veeam Software
Posts: 21139
Liked: 2141 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Incredibly slow Direc SAN restore

Post by foggy » 2 people like this post

I've checked this further and actually during restore Veeam B&R sets the LUN to write mode (like it is mentioned here), so it should in fact work automatically, without the need to bring the LUN online. I recommend contacting support in each case when this does not occur, since there're several reports regarding this, there might be something that needs our attention.
Post Reply

Who is online

Users browsing this forum: No registered users and 20 guests