Backing up Server 2012 To Freenas CIFS share

[Prime03]

Hey all, I've been a casual Freenas user for sometime at work. My system is currently only being used to back up a couple Linux machines, but I'd like to also back up a few Windows Server 2012 machines to it as well.

I appear to have the CIFS share set up correctly... I've set up the users correctly, and I've set up the back up user on the 2012 machine and mounted the network drive. Tested permissions, copied files and executed them, etc....

I'm trying to stick to using the built in windows server backup function(The free route), but I'm getting trouble every time I try to initiate a backup. The back up begins creating the shadow copy process, eventually hangs for a few minutes, then all of the following steps proceed to fail. At this point I've only tried setting up the backup process to an old 2003 server and it appears to work fine.

I figured maybe the samba version being used by Freenas on the CIFS share was the issue so I set the minimum protocol to 3, still no luck.

At this point I'm considering attaching another local drive and backing up to it, then transferring the files using powershell, but I'd rather avoid going that route.

Has anyone else encountered similar issues backing up a windows 2012 server to their Freenas box?


Thanks for your time!

 

[Robert Smith]

How about backing up to iSCSI; would that work for you?

 

[Prime03]

Robert,


Ive thought about reading up on iSCSI. I'm not experienced with iSCSI at all, never used it, and never read about it, but I have a basic understanding of the concept.

I would have to assume I would be able to use iSCSI with my existing zpool?

 

[Robert Smith]

If your FreeNAS hardware is up to spec, I do not see why not.

 

[Prime03]

Ok so I got in this morning and I managed to get it to work, thanks for pushing me in that direction!

In reading the Freenas documentation for iSCSI, I came across this bit...

NOTE: an iSCSI target creates a block device that may be accessible to multiple initiators. A clustered filesystem is required on the block device, such as VMFS used by VMWare ESX/ESXi, in order for multiple initiators to mount the block device read/write. If a traditional filesystem such as EXT, XFS, FAT, NTFS, UFS, or ZFS is placed on the block device, care must be taken that only one initiator at a time has read/write access or the result will be filesystem corruption. If you need to support multiple clients to the same data on a non-clustered filesystem, use CIFS or NFS instead of iSCSI or create multiple iSCSI targets (one per client).

I foresee issues if I have 3 machines all backing up at one time in the middle of the night. I guess the simple solution would be to stagger them, but I'll likely add more than just 3 machines. What kind of implementation am I looking at to be able to have multiple initiators mount the same zfs device extent and write without concern of corruption?

Thanks!

 

[cyberjock]

The note hints at the "solution"... you need a clustered filesystem. The problem... all desktop versions of Windows don't support clustered file systems AFAIK. That's why the note also recommends you use NFS or CIFS instead or create multiple iSCSI targets. :)

 

[Robert Smith]

Each Windows backup configuration should use its own target no matter the kind, anyway. If you do not like iSCSI, try VHD (also one per server).

 

[Prime03]

The note hints at the "solution"... you need a clustered filesystem. The problem... all desktop versions of Windows don't support clustered file systems AFAIK. That's why the note also recommends you use NFS or CIFS instead or create multiple iSCSI targets. :)

Yeah I saw the hint that was dropped, but I'm not a file system guru, so when you prefix it with clustered, I get the chills. I'll have to look into it as well at some point when I get the chance.

My original reason for making the thread was the backup process was failing to a CIFS share, although I haven't tried NFS as well, I figured it would also be problematic. I'll have to try it as well when I get the chance.

Each Windows backup configuration should use its own target no matter the kind, anyway. If you do not like iSCSI, try VHD (also one per server).

The thought of setting up a target for each machine never crossed my mind, makes total sense though. Is there a way to set up a dynamically expanding iSCSI target? Should I use a file extent on a dataset rather than a device extent on a zvol? What would be the preferred method?

 

[Robert Smith]

File extents should work just fine.

Also, once you are done setting the backup up, do not forget to test bare metal recovery. You may need to make your own recovery boot disk or stick, as I do not know if Microsoft has started including iSCSI initiator on the standard one.

 

[Prime03]

I've been looking into the baremetal recovery metal from iSCSI. I think I'm satisfied with the option of sharing the target from another windows machine to the network if it comes down to it. Unless there's a better way then modifying an installation disc that you've heard of.

 

[cyberjock]

So here's the problems:

iSCSI - requires clustered FS (not supported on desktop OSes). Kind of hacky and unreliable to share out an iSCSI via CIFS or NFS through a client machine. Definitely not recommended.
NFS - slow and not supported on anything except the most expensive versions of Windows (ultimate, etc.)
CIFS - works well unless something is not right (which is your case)

You should try burning CDs! I'm kidding of course. I would focus on why the CIFS backups aren't working. I know that back when I had server 2008 the backup software it had would let you backup to a CIFS share, but if you had to do a recovery you couldn't. Kind of pointless eh? I have no idea if this has changed or not, but after I figured out you couldn't do recovery from the network I gave up and just used a second disk installed in the system. I have no idea if the desktop versions of Windows suffer from the same limitations or not.

 

[Robert Smith]

I would not touch the desktop Windows backup on anything past Windows 7 with a 10-foot pole.

Microsoft broke the backup badly in Windows 8.

 

[Ericloewe]

I would not touch the desktop Windows backup on anything past Windows 7 with a 10-foot pole.

Microsoft broke the backup badly in Windows 8.

Windows 7's standard image-based backup is still available in 8+.

 

[Prime03]

I would not touch the desktop Windows backup on anything past Windows 7 with a 10-foot pole.

Microsoft broke the backup badly in Windows 8.

Could you elaborate a little further? What is wrong with it? Could you suggest any alternatives that don't cost an arm and a leg?

Windows 7's standard image-based backup is still available in 8+.

I'm doing a full VSS backup route on one machine at the moment because it's a hyper-v host, do you see any negatives? I've yet to try a BMR from the server backup utility, better yet one from an iSCSI drive, but I'm considering throwing together a dummy machine to try it on.

So here's the problems:

iSCSI - requires clustered FS (not supported on desktop OSes). Kind of hacky and unreliable to share out an iSCSI via CIFS or NFS through a client machine. Definitely not recommended.
NFS - slow and not supported on anything except the most expensive versions of Windows (ultimate, etc.)
CIFS - works well unless something is not right (which is your case)

You should try burning CDs! I'm kidding of course. I would focus on why the CIFS backups aren't working. I know that back when I had server 2008 the backup software it had would let you backup to a CIFS share, but if you had to do a recovery you couldn't. Kind of pointless eh? I have no idea if this has changed or not, but after I figured out you couldn't do recovery from the network I gave up and just used a second disk installed in the system. I have no idea if the desktop versions of Windows suffer from the same limitations or not.

HA, might as well get out the floppies while I'm at it.

I spent a fair amount of time tinkering with the CIFS share, and I was unable to get the server back up utility to work, and there wasn't much out there that referred to stuff I hadn't already tried. I will re-approach it at a later date I guess.

Could you enlighten me a bit when you say iSCSI requires clustered FS? What is running that file system? Who is providing it. Why is it not supported by desktop OSes? How would user machines utilize that iSCSI storage space? I don't mind going the extra disk route, but unfortunately most of the machines have full bays.

 

[Robert Smith]

Windows 7's standard image-based backup is still available in 8+.

Yes, that is the one I was talking about.

I had restored Windows 7 machines many times with not a single issue. The first time I needed to restore a Windows 8 machine, it refused with a cryptic catch-all error message. (It may have had something to do with cloud software conflict, but I did not pursue the issue further, and restored from plan B. The backup should work reliably regardless of what client software is installed on a workstation.)

I lost trust in Windows backup. I pay for other tools that work; and I would use a free third party backup instead of what Microsoft has in Windows 8.

 

[Prime03]

Yes, that is the one I was talking about.

I had restored Windows 7 machines many times with not a single issue. The first time I needed to restore a Windows 8 machine, it refused with a cryptic catch-all error message. (It may have had something to do with cloud software conflict, but I did not pursue the issue further, and restored from plan B. The backup should work reliably regardless of what client software is installed on a workstation.)

I lost trust in Windows backup. I pay for other tools that work; and I would use a free third party backup instead of what Microsoft has in Windows 8.

I see where you're coming from, I certainly can understand. You've instilled the need to test this backup fully at the first possible opportunity, which will hopefully be tomorrow.

 

[cyberjock]

Could you enlighten me a bit when you say iSCSI requires clustered FS? What is running that file system? Who is providing it. Why is it not supported by desktop OSes? How would user machines utilize that iSCSI storage space? I don't mind going the extra disk route, but unfortunately most of the machines have full bays.

Sorry but that question is far beyond the scope of this forum. Not to mention it is extremely complex and there are entire books devoted to this subject.

 

[Prime03]

Sorry but that question is far beyond the scope of this forum. Not to mention it is extremely complex and there are entire books devoted to this subject.

Yeah I feel that way as well lol, I appreciate your help regardless! Hopefully one day I'll find myself in front of one of those books.

 

[Robert Smith]

Could you elaborate a little further? What is wrong with it?

Yes, the problem is the occasional error 0x80070057 that you get when doing bare-metal restore. Sometimes you can get past the error by unplugging the boot device at the right moment, sometimes you cannot.

Way too unreliable for my liking.

 

[Prime03]

Ok so I've done some more exploring, and I need to report back with what I've come across, because at this point I am absolutely stumped. Hopefully somebody much wiser than me can envision the issue and guide me in the right direction.

After attempting to do a BMR from an iSCSI multiple ways, it was an absolute failure. I've considered continuing down this route, and if I ever need to do an actual recovery, transfer the files from the iSCSI to a legit CIFS share. Either way, there's a lot of steps involved, and this would be a last resort scenario. I much prefer the usability and control of a CIFS share.

So I began looking into my CIFS issue further. I'll try and give a more detailed background of the setup. Basically I have 3 Windows 2012 Servers that I need to be backing up, and I would for all intensive purposes, love to do it to my Freenas storage box.
1 - Windows 2012 Server R1 / IIS / Hyper V
2 - Windows 2012 Server R2 / SQLserver (Fresh Install)
3 - Windows 2012 Server R2 / Test machine (Fresh Install)

Using the Windows Server Backup utility, I'm only able to successfully backup up to a CIFS share on machine #3. Initially I figured it was an issue between R1 and R2, so I was planning on upgrading the R1 machine. This was until I tried backing up machine #2 to the freenas box, and it also failed. I immediately began to compare roles and features between the R2 machines, and found nothing substantial that should cause an issue. I've tried changing the backup type from VSS full to copy, I've tried changing the min/max SMB protocol for CIFS on freenas to the lowest and highest settings.

I began to think after reading another thread about all the the "deadlock errors trying to look up SID xxxx", I felt like it was possible my permission setup could be causing this. (even though all 3 machines follow the same setup, 1 works, 2 don't)

I have a single group that contains a single user for this CIFS share. There are no other shares on this volume. I have the Owner/Group set to this backup user/group with the windows permissions option set on the CIFS dataset. All 3 of the Windows machines have a user with the same name and password as the freenas account, and they are all members of the backup operator group under windows. I'm able to create a network location on all 3 machines and successfully write to all folder levels without issue. So I believe my permissions shouldn't be an issue, but I thought I'd explain them anyways in case something stands out to somebody.

All 3 of these machines are able to successfully back up to a Windows 2003 share, as well as an iSCSI drive without issue. Can anyone save me from my misery? If there's any more information I can provide please let me know. (I'm willing to abandon using the built in Windows Server Backup utility altogether, but at this point in time I'm not willing to spend a dime on it.)