-
- Expert
- Posts: 121
- Liked: 6 times
- Joined: Mar 24, 2010 12:15 pm
- Full Name: Mark Fellows
- Contact:
DR - Very Easy But Slightly Slower Than Expected
We’ve just returned from our annual disaster recovery test and this is the first year we’ve had our virtualised Windows infrastructure. We restored the virtualised portion of our infrastructure in around 6.5 hours (only 6 Vms, around 1TB). This was a little slower than expected (but still much quicker than the restoration of the 4 physical servers!!). The speed was largely down to the encrypted usb device we used and the uploading of the ‘white space’ to create the thick disks on our ESXi server.
Once the test was completed I experimented with some alternative recovery methods, e.g. instant recovery then Storage vMotion etc. Restoring our VMs using the ‘forced thin disks’ method was obviously quickest as the amount of true data on these machine is no where near the thick disk size.
A couple of things :
1. I was just wondering what are the risks of restoring in this manner? Veeam recommend restoring in the same format as the original.
2. Once restored is it ok to continue to run as a thin disk or is it best to Storage vMotion back to a thick disk. Is one solution riskier that the other? (Apart from monitoring the size of thin disks)
3. Would the functionality mentioned by tslighter in this post (http://forums.veeam.com/viewtopic.php?f ... thick+thin), thin restore then an automatic conversion to thick, be considered in future versions?
We do intend to replicate off site with v6 but I was just inquisitive for future VM restores.
All in all the ease of our recent disaster recovery test only went to prove what a great piece of software this is, everything restored without issue!!
Once the test was completed I experimented with some alternative recovery methods, e.g. instant recovery then Storage vMotion etc. Restoring our VMs using the ‘forced thin disks’ method was obviously quickest as the amount of true data on these machine is no where near the thick disk size.
A couple of things :
1. I was just wondering what are the risks of restoring in this manner? Veeam recommend restoring in the same format as the original.
2. Once restored is it ok to continue to run as a thin disk or is it best to Storage vMotion back to a thick disk. Is one solution riskier that the other? (Apart from monitoring the size of thin disks)
3. Would the functionality mentioned by tslighter in this post (http://forums.veeam.com/viewtopic.php?f ... thick+thin), thin restore then an automatic conversion to thick, be considered in future versions?
We do intend to replicate off site with v6 but I was just inquisitive for future VM restores.
All in all the ease of our recent disaster recovery test only went to prove what a great piece of software this is, everything restored without issue!!
-
- VP, Product Management
- Posts: 6033
- Liked: 2859 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
So I personally don't think there is any real risk to restoring in thin vs thick mode.
Many customers run their pretty much their entire environments as thin, so no real reason to be forced to convert There are some pretty noticeable performance penalties to thin disks when it comes to heavy writes that require growth of the thin VMDK, however, for most workloads this is rare. That being said, it is very easy to "restore thin" and then "inflate" the disk via the Datastore browser in the vCenter client prior to powering on the system.
In the end though, this may not matter. V6 will change things significantly, once you have at least one VM up and capable of hotadd you can perform the other restores via hotadd which is a lot faster and basically gives you the benefits of agent mode even on ESXi. Then you can just restore as thick, the same as your source, and the restore should still be fast, probably faster then a thin restore with V5 to ESXi.
Many customers run their pretty much their entire environments as thin, so no real reason to be forced to convert There are some pretty noticeable performance penalties to thin disks when it comes to heavy writes that require growth of the thin VMDK, however, for most workloads this is rare. That being said, it is very easy to "restore thin" and then "inflate" the disk via the Datastore browser in the vCenter client prior to powering on the system.
In the end though, this may not matter. V6 will change things significantly, once you have at least one VM up and capable of hotadd you can perform the other restores via hotadd which is a lot faster and basically gives you the benefits of agent mode even on ESXi. Then you can just restore as thick, the same as your source, and the restore should still be fast, probably faster then a thin restore with V5 to ESXi.
-
- Expert
- Posts: 121
- Liked: 6 times
- Joined: Mar 24, 2010 12:15 pm
- Full Name: Mark Fellows
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
Thanks for the reply.
Had a quick look at my backup logs and noticed one of my VMs is not using HotAdd to back up (failing over to network mode). I'll get this resolved ready for v6.
Had a quick look at my backup logs and noticed one of my VMs is not using HotAdd to back up (failing over to network mode). I'll get this resolved ready for v6.
-
- Expert
- Posts: 121
- Liked: 6 times
- Joined: Mar 24, 2010 12:15 pm
- Full Name: Mark Fellows
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
We have started planning for this year’s DR test and I just wanted to get the opinions of forum members as to recovery options.
Last year’s scenario was described in the original post and went well but obviously I want to make the process as quick as possible with the resources we have. To summarise we take the .vbk files located on a pretty slow encrypted USB drive to a 3rd party DR center and attach the device to a standalone PC with Veeam installed. The VMs are then restored to the local storage of the ESXi 4.0 host.
For this year’s test I was looking to speed things up a little and was hoping the changes mentioned by Tom (above) in v6 would help. Would the following scenario be any quicker (I’m hoping it would) than last year’s restoration process.
1). Attach the USB drive to the stand alone PC and restore the Veeam server VM onto the Esxi server
2). Map the USB drive from the stand alone PC over the 1Gbp network and connect to this via the Veeam VM on the ESXi server. Can’t directly add the USB device to the ESXi server as USB pass through isn’t supported in Esxi 4.0.
3). Restore the remaining VMs from the Veeam Server VM as I presume this would take advantage functionality
In future tests we may look to take our offsite backup store (ReadyNas) but we have always been wary about this due to the lack of encryption. Failing that we will look to upgrade to a later version of ESXi to at least allow for USB pass through.
Any suggestions for alternative methods are more than welcome.
Last year’s scenario was described in the original post and went well but obviously I want to make the process as quick as possible with the resources we have. To summarise we take the .vbk files located on a pretty slow encrypted USB drive to a 3rd party DR center and attach the device to a standalone PC with Veeam installed. The VMs are then restored to the local storage of the ESXi 4.0 host.
For this year’s test I was looking to speed things up a little and was hoping the changes mentioned by Tom (above) in v6 would help. Would the following scenario be any quicker (I’m hoping it would) than last year’s restoration process.
1). Attach the USB drive to the stand alone PC and restore the Veeam server VM onto the Esxi server
2). Map the USB drive from the stand alone PC over the 1Gbp network and connect to this via the Veeam VM on the ESXi server. Can’t directly add the USB device to the ESXi server as USB pass through isn’t supported in Esxi 4.0.
3). Restore the remaining VMs from the Veeam Server VM as I presume this would take advantage functionality
In future tests we may look to take our offsite backup store (ReadyNas) but we have always been wary about this due to the lack of encryption. Failing that we will look to upgrade to a later version of ESXi to at least allow for USB pass through.
Any suggestions for alternative methods are more than welcome.
-
- VP, Product Management
- Posts: 27357
- Liked: 2788 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
You will definitely benefit from having an ability to restore VMs through HotAdd mode, though the overall performance will depend on the link between your standalone PC and Veeam backup server.
To use HotAdd mode, you need to make sure your default proxy server/Veeam server is located on the ESX(i) host which has direct connect to the datastores you're restoring VMs to.
To use HotAdd mode, you need to make sure your default proxy server/Veeam server is located on the ESX(i) host which has direct connect to the datastores you're restoring VMs to.
-
- Expert
- Posts: 121
- Liked: 6 times
- Joined: Mar 24, 2010 12:15 pm
- Full Name: Mark Fellows
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
Thanks Vitaliy, as a slight aside what's the easiest method to determine whether Hot Add had been used during Backup/Restore. This was fairly easier to spot in v5 but can’t seem to locate it in v6.1.
-
- VP, Product Management
- Posts: 27357
- Liked: 2788 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
Open the session log (right-click the restore session and select the Log tab) and find the "Using target proxy..." record. Check whether it has the [hotadd] label after the name of the proxy. That means that the hotadd transport mode is effectively used to populate VM data on the target host.
-
- Expert
- Posts: 121
- Liked: 6 times
- Joined: Mar 24, 2010 12:15 pm
- Full Name: Mark Fellows
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
Thanks Vitaliy, how about backups?
-
- VP, Product Management
- Posts: 27357
- Liked: 2788 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
You should also look at the backup job session for this kind of info.
-
- Veteran
- Posts: 261
- Liked: 29 times
- Joined: May 03, 2011 12:51 pm
- Full Name: James Pearce
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
Re encrypted USBs, just to add that in my experience things move along much more quickly using partition-level encryption, rather than creating a file-based container.
-
- Expert
- Posts: 121
- Liked: 6 times
- Joined: Mar 24, 2010 12:15 pm
- Full Name: Mark Fellows
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
Thanks J1mbo, yes were currently using partition level encryption and have found this quicker than file based countainers.
Does anyone know where I can find the Hot Add info in the backup log (mentioned above).
Does anyone know where I can find the Hot Add info in the backup log (mentioned above).
-
- VP, Product Management
- Posts: 27357
- Liked: 2788 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
Hi Mark, please take a look at our User Guide (page 222) for the screenshot of the session log (search for "Using source proxy..." line).
-
- Expert
- Posts: 121
- Liked: 6 times
- Joined: Mar 24, 2010 12:15 pm
- Full Name: Mark Fellows
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
Hi Vitaliy, I had already taken a quick look at the user guide (not a detailed one though I must admit!!). The screenshot in the v6.1 user guide looks slightly different from what I'm seeing, is this screenshot definitely from v6.1??
I don’t have a line “Using source proxy…”. I also have some additional details e.g. lines in the action pane detailing the load percentages and the primary bottleneck.
I don’t have a line “Using source proxy…”. I also have some additional details e.g. lines in the action pane detailing the load percentages and the primary bottleneck.
-
- VP, Product Management
- Posts: 27357
- Liked: 2788 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
Have you clicked on one of the VMs on the left pane to see its detailed session log?
-
- Expert
- Posts: 121
- Liked: 6 times
- Joined: Mar 24, 2010 12:15 pm
- Full Name: Mark Fellows
- Contact:
Re: DR - Very Easy But Slightly Slower Than Expected
Just about to post to say I needed to click on the VM!! Thanks Vitaliy, only recently upgraded from v5 so I'm still exploring!
Who is online
Users browsing this forum: Bing [Bot], Google [Bot], Gostev, renatorichina, tkado, uk1984 and 109 guests