1

I have two servers, both running Windows Server 2016 Standard, both are VMs on top of a Windows Server 2016 Standard Host, using Hyper-V.

One server runs a service that needs to store data on a local file system, that is, something with a drive letter. No UNC paths, no SMB, no Authentication.

The other server is a file server.

What I would like to do is for the application server to store the application data on the file server. I can do this via iSCSI, which creates a VHDX on the File Server. This works fine, the application successfully stores its data on this hard drive.

However, I would like to make backups of the content of the VHDX, and ideally have that done on the file server. For that, I would need to mount the VHDX - but I can't do that, because it "is in use by another process". That's a bummer.

Is there a (supported) way to keep a VHDX mounted read-only on the File Server while sharing out over iSCSI? I am not worried about the application server trying to format or create partitions or something. I'm flexible on the file system (NTFS, ReFS or even ExFAT).

I wondered if I should just move the VHDX to the physical host machine and then attach it to both VMs as Shared Hard Drives, but it seems that this is meant for failover clustering.

Maybe iSCSI and VHDX isn't the right approach here, are there other supported ways to have one drive letter on Server A actually write data to a location on Server B in a way that Server B can access the files, while still being able to use Volume Shadow Copies (VSS) for backup purposes? (and yes, installing a backup agent on Server A is a possibility, but I want to keep things as simple as possible - I realize iSCSI might be overkill as I'm sharing an entire block device out, when really, I just want a shared folder).

  • 1
    I want to keep things as simple as possible - TBH, you're not on the "simple" path at the moment. Why not attach the virtual hard drive to the application server as you would for any other VM and then use Windows Server Backup on the application server to backup the files to a share on the file server? – joeqwerty Jul 17 '17 at 21:59
  • 1
    @joeqwerty yeah, maybe simple isn't the right word, my line of thinking is more like "I have this one server that has all the stuff in it, so I only have to worry about backing that one up, everything else is disposable". The iSCSI approach means that all data is on the file server immediately, and I don't need to provision extra disk space for the Application Server. – Michael Stum Jul 17 '17 at 22:05
  • (But I'm not dead-set on the approach. This system is mostly used by me, so I'm trying to find the way that gives me the lowest management overhead without jeopardizing data) – Michael Stum Jul 17 '17 at 22:06
  • OK, I see what you're after. While it might be desirable to set this up the way you've described, I think you're adding unnecessary complexity and potential for data loss and/or corruption. – joeqwerty Jul 17 '17 at 22:08
1

Making long story short: you can't do that. Even in a single writer mode nobody is going to update your sibling reader about metadata changes on a block volume: unmount/mount sequence would be needed to update second "shadow" $MFT.

|improve this answer|||||
0

How about running net use x: \\fileserver\smbshare on the application server, which mounts the share to drive x: on the application server?

And no, I don't think you can mount the iSCSI target on the fileserver at the same time as it is being used on the application server. The fileserver would have no way to know how the filesystem internal data has been updated by the application server. Therefore any new files created / existing files extended would not be seen by the fileserver, and backups would be useless.

|improve this answer|||||
  • net use would be exactly what I want, but looking at this question and discussions like there it doesn't seem to reliably work without a user logging in. Still, might be my best bet. – Michael Stum Jul 18 '17 at 11:06
  • 1
    Hey, "net use" might be your best and the only one solution, because it is impossible to read and write from 2 sources, the metadata will be an updated and that will lead to the data corruption. – Net Runner Jul 24 '17 at 13:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.