• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Looking for advice on WHS

W

williamlee

n00b
Joined
Aug 1, 2009
Messages
25
This is directed to all the WHS experts out there..

I am currently running a number of linux RAID6 boxes, and one OpenSolaris ZFS box so I am familiar and comfortable with setting up a home storage server.

I also have a spare older Intel server board with dual 32 bit Xeon processors, a PCI-X SuperMicro Sata card (in a PCI-X slot), 4 gigs of ECC memory, 2x1TB HDs, 2x1.5TB HDs, and 1 120gig old IDE HD. I recently installed WHS on it to play around with. Since I also run a mix of Windows 7 and XP PCs on my main workstations in the house, I like a lot of the featurs of WHS so far, especially the automated backups of the Windows PCs, and the storage pool.

That said, I have a major concern with the issue of no apparently easy way to backup the WHS OS drive. I don't want to depend on WHS figuring out how to rebuild my pool by reinstalling it on a new OS drive in the case of an OS drive failure. One of the big reasons I run software linux raid is the ability to troubleshoot things by hand in the case of a failure, and the ease of swapping failed hardware.

Does anyone have a suggestion on how to work around the fact the WHS does not allow for an OS drive backup? I've tried googling and reading up on this stuff, and haven't come across anything that I'm comfortable with. One thought I had would be running WHS on a VM within a Linux raid setup, but I'm not sure if that's viable or makes sense as a solution.

I am hoping someone has a creative workaround since I know there are a lot of WHS fans on this forum. For me personally, it's not enough that WHS should rebuild itself with a new OS drive in the event of an OS drive failure. In searching the forums, I've seen more than one case where this didn't work out for the user. I don't know if it was user error or not, but I don't want to depend on a blackbox for recovery. Any suggestions would be greatly appreciated. Otherwise, I feel like my comfort level is not going to be high enough to commit to WHS.

I'm also open to other suggestions for this box.
 
What some people have been doing is setting up a RAID 1 array for the OS drive. Maintains system uptime that way
 
WHS v2 Vail has OS backup native... but only runs on 64bit hardware....

I have run WHS V1 with a RAID 1 array for OS and I am currently doing the same for WHS V2

the OS backup feature is nice as long as you have all data backed up also.

with V2 you can migrate foregn drive pools into the OS so reinstalling after a OS drive failure no longer is the same pain...

for multiple reasons :D
 
You could also run it in a VM. Been running WHS on my 2k8 server in a hyper-v instance. Using a dynamically expanding VHD, max is like 2040GB, but you could set a static one higher IIRC.

Any-who, it's easier to change hardware. I can move to any RAID or server platform that I want...and I have probably changed what server I'm running at least half a dozen times over the past few years that I've been running this same instance. It's been 100% solid, no problems, minus the note below.

Now, having said that, I still think the overall I/O of WHS for shares frankly blows. So, my WHS is only used for system backups. Then I do an automated mirror of said VHD once a week to another source.

Good luck and have fun. :)
 
Adidas4275 said:
with V2 you can migrate foregn drive pools into the OS so reinstalling after a OS drive failure no longer is the same pain...

for multiple reasons :D
Click to expand...

I didn't know this. That and being able to back up the OS are really the only reasons I see to move to Vail at all. And it's mind numbing that you can't do either of these in V1.
 
Can you not install WHS on the same drive as data?

I was going to go with two drives in RAID1 with data + WHS on, is that not possible or do people just generally like to keep the two separate?
 
You can do what you speak of but people usually don't for a variety of reasons. It's probably a good practice to separate them.
 
There are a couple things you can do that I can think of, but all of them involve RAID and all of them are not 'officially' supported.

1. RAID 1 System Drive, All Data Drives added individually and data protection is managed by WHS. This seems to be the most common method.

2. RAID 1 System Drive, RAID 5/6 Data Drives, WHS uses one giant pool and folder duplication is pointless (and not needed).

3. RAID 5/6 All Drives, Install WHS on top of that, folder duplication still pointless but entire system follows regular RAID rules while having the software benefits of WHS.

4. Virtualize WHS. This method seems to require one of the other previous methods to ensure that data is protected, so I don't see the point unless you have a system thats already virtualizing other servers.

As previously stated, Vail seems to be better at recovering from a system drive failure, but there are a couple other things to consider, particularly the new inner workings of Drive Extender, before committing to that.

-Cool-
 
But if you make an array over 2 TB WHS won't be able to see it all, no?
 
There is no reliable method to back-up the WHS OS drive. The core problem is the way that WHS v1 implements 'drive extender' (DE). DE uses a concept called "tombstones", which is really a funky kind of index that maps where actual files are stored for the user shares. The "tombstones" are implemented as symbolic links to the files stored in the actual DE drive array.

The problem comes because DE likes to move files around. It has a process that runs periodically to manage the drive pool and manage file duplication (the "demigration process"). In the "demigration" process, it moves files around and updates the tombstones. And here's the problem: the tombstones are kept on the OS drive.

If you take a snapshot of the OS drive and then let WHS keep running for some period of time, you are almost guaranteed to have the tombstones saved in your backup (or VM drive snapshot) point to non-existent places in the shares, have files in the shares with no tombstone to reference them, or - worst case of all - perhaps even have tombstones that point to the wrong file. This would be disastrous.

On the upside, the Shares actually contain enough information to reconstruct the tombstones. This works as long as WHS itself is not publishing the shares (they are effectively offline). This is what WHS does when you "reinstall" - it re installs the WHS OS and then, before it actually puts itself online - scours through the shares to rebuild the tombstones (rebuild its index, if you will). What might be nice is if WHS had a way to tell it "OS, I've restored from a backup - now go wipe out the tombstones and rebuild them for me". Unfortunately, it does not have this.

WRT the suggestions above, the only viable one is to increase the reliability of the OS drive so that it is less likely to fail. The "use raid-1 for the OS drive" suggestion does this. Note that raid is not the same as a backup - but it certainly does reduce the probability of losing the OS drive. Be aware that WHS makes building a raid-1 OS drive a royal PITA - it is not to be undertaken lightly...

The "run it in a VM" approach can be a good way to get WHS running on a highly-reliable OS drive more easily. Installing WHS in a VM - especially if you are using Hyper-V as your host - is really quite simple. When you do this, make sure the OS drive image is stored on a drive protected by Raid. Then you have all the advantages of running the OS drive as Raid but none of the PITA of trying to get WHS to install itself on a raid drive. But DO NOT attempt to snapshot the virtual drive and think you've outsmarted MicroSoft and their silly "you can't back up the OS drive" problem. You haven't. If you use a backed-up image of the VM and let it start to manage the drives in your drive pool you will be screwed completely because the index stored on the OS drive (the tombstones) will not match the data stored on your shared drives.

The best approach is to move to Vail - when it is released - because it does not have this same problem. It has new problems, to be sure, but it does not have this one.
 
Last edited:
PigLover said:
There is no reliable method to back-up the WHS OS drive. The core problem is the way that WHS v1 implements 'drive extender' (DE). DE uses a concept called "tombstones", ............ What might be nice is if WHS had a way to tell it "OS, I've restored from a backup - now go wipe out the tombstones and rebuild them for me". Unfortunately, it does not have this.
Click to expand...

Nice, easily read and understood explanation PigLover!

The idea about rebuilding tombstones would have saved many users from big problems and fixed a major flaw in WHS.
 
Thanks for all the replies...

Just wanted to provide an update...I decided to give it a shot running WHS in VirtualBox as a guest on an Ubuntu OS. I decided to keep things relatively simple and created two RAID1 arrays in mdadm (2x1TB, 2x1.5TB). I used a bridged network connection so WHS could see my Windows PCs.

The WHS OS is on a VDI file on one of the RAID1s. I created another 1TB VDI file on the RAID1 and added it to the WHS storage pool. I may create a 2nd on on the other RAID1 and add that also in the future.

So far everything is running fine. WHS can see my Windows 7 box, and will do its first backup tonight. Hopefully there won't be any issues down the road running it virtual, but looking good right now.
 
So I just tried copying a folder to WHS on the VM, and I'm only getting around 3.5MB/s on average transfer speed. Any ideas on improving this?
 
Whats the full setup?
Are you passing the disk directly to the VM? or making VHDs? You should be using disk passthrough and not creating VHDs with the exception of the OS drive.
 
nitrobass24 said:
Whats the full setup?
Are you passing the disk directly to the VM? or making VHDs? You should be using disk passthrough and not creating VHDs with the exception of the OS drive.
Click to expand...

I did not pass the disk straight through. I will look into trying that, and keep you posted.

Thanks!
 
OK, with passing the disk straight through I am getting 5MB/s on average which is an improvement, but still slow. Any other suggestions?
 
What's your hardware setup like, for both your server and your client?
 
You must log in or register to reply here.
Back
Top