DR - Very Easy But Slightly Slower Than Expected

[markfellows]

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!!

[tsightler]

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.

[markfellows]

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.

[markfellows]

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.

[Vitaliy S.]

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.

[markfellows]

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.

[Vitaliy S.]

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.

[markfellows]

Thanks Vitaliy, how about backups?

[Vitaliy S.]

You should also look at the backup job session for this kind of info.

[J1mbo]

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.

[markfellows]

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).

[Vitaliy S.]

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).

[markfellows]

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.

[Vitaliy S.]

Have you clicked on one of the VMs on the left pane to see its detailed session log?

[markfellows]

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!