Storing OS/Data VHD's on Separate Volumes

[pearsonsjp48]

Maybe somebody can come up with a better solution, but we only recently discovered that our Veeam B&R doesn't pick up on iSCSI drives.

This isn't a showstopper, but it doesn't go well with what we had planned. Right now we are in the process of building out our infrastructure as follows:

We run a Hyper-V environment and manage most of it through SCVMM.

All of our C: drives are stored in a single volume, per Veeam recommendation. This allows us to take regular snapshots. All well and good.

Each data drive has its own separate volume. We had been connecting this through the Nimble Connection Manager as an iSCSI drive. We would like to maintain this separation for several reasons. (Different protection policies for one)

While this still allows us to back up our data through snapshots, it takes Veeam out of the equation, which is an issue for us. I don't want to have a patchwork backup solution where we might need to restore from multiple locations. Also while Nimble snapshots are application aware, they don't offer the features I have with Veeam (I can't easily, if at all, restore them into the SureBackup sandbox...I can't restore individual records/tables from a SQL database). The only restore I've had to do in recent history was to pull a database table from the night before without wiping data entered since then. There are ways to get this done yes, but Veeam made the process almost instantaneous which is why we're paying for it.

The most sensible thing to me would be to create a VHD within the Nimble data volume then attach that to the VM. I manage to do this, but the VM failed to start. I'm not an expert in Hyper-V or server clusters, I can only guess that the cluster manager doesn't like trying to managing VM's with resources that are split like that?

I also toyed with making the volume available to the host through iSCSI then attaching the volume as a physical drive to the VM. The attach worked and the VM booted up but the new volume didn't show within the guest OS. I know VSS snapshots wouldn't work (thus breaking Veeam) anyway, that was more an experiment on my part to see what I could learn from the process.

Does anybody have a process nailed down to achieve this? End result would be having data volumes for each VM, OS drives for each VM together in the Quorum, and backing up everything from within Veeam.

Migrating to VMware is off the table, just though I'd throw that out there.

[Valdereth]

Hello,

Veeam Endpoint Backup Free can be installed within your guests to backup the data from the drives you select, or the entire system.  If you point them to your Veeam repository then you'll get the granular recovery options you're looking for.  They'll be adding licensed versions of these clients and calling it the Veeam Agent for Microsoft Windows that will bring centralized management and better support.

Unless you have a need for in-guest iSCSI I'd consider moving your data to VHD's.

[pearsonsjp48]

We already use Veeam Endpoint Backup for a few legacy servers. I suppose I never even tried a recovery from one of these servers and it appears it does in fact give us those recovery options. (I had assumed that since they weren't set in the backup plan that they weren't available) This does help provide an interim solution. But it isn't quite the solution I'm looking for.

"Unless you have a need for in-guest iSCSI I'd consider moving your data to VHD's."

Yes, this is exactly what I'm asking for help for; and ultimately what would bring us to the state I would like to have.

As I'd mentioned - creating a volume and placing a VHD within that volume, then attaching that VHD to a VM puts the VM in a fail state. I'm not sure why this happens. So if anybody has experience in doing such a thing, this is where I need help!

[chris24 · Accepted solution]

Hello,

Moving to VHD's will give you the 'Veeam' advantages you are looking for, you can still keep the granularity of different volume collections. Have one volume per VHD / application / VM, this is highly recommended for the benefits of reporting on performance.

The failed state will most likely be because of a configuration issue, you can absolutely have VHD's spread across volumes, call Nimble support they will be able to help you.

Converting your direct attached from iSCSI to VHD's depending on your application can be achieved via copy operations or with https://www.microsoft.com/en-gb/download/details.aspx?id=42497

Cheers,

Chris

[pearsonsjp48]

Thanks Chris!

Per your advice, I went back and attempted the process again. When I had attempted this before I was certain it would work and was completely thrown off by the fail state.

I took extra care with each step this time and it worked perfectly. Not sure what I had done wrong the first time, but I nailed down the process and have liftoff.

Also, the iSCSI to VHD conversion will be next on the table. I've used that converter tool for some other things, though I'm thinking I can simply create a VHD and attach it -> Copy the data over -> Remove the iSCSI -> Map the VHD to the appropriate drive letter (effectively replacing the iSCSI). I see no reason why this wouldn't work.

All during non-business hours and after backing everything up, of course. ;-)

Thanks again!