Running On Windows Server?

[Taddeusz]

Originally Posted by Skirge01

For some sort of protection of my recordings, I went with FlexRAID. It's not proprietary and does not change the data, so nothing is lost if the mobo dies, the RAID card fries, or the OS takes a dirt nap. It uses parity on a separate drive, but your data drives can be of any size and speed. Also, if you happen to lose more than your fault tolerance (I can explain that, if you want), the data on your still functioning drives will remain live and accessible.

But FlexRAID would still be susceptible to the very same bit rot that can prevent a RAID 5 array from being restored following a failure. FlexRAID is basically, sort of, RAID 5 for mixed size drives. Except that the parity is not spread across all drives as in RAID 5. You can't get around the bit rot though. No amount of redundancy can.

[PeteCress]

Do I dare install the latest version of Java for WindowsXP?

After, of course, stopping the SageTV service... -)


Also, is this condition affecting the timing of my recordings?
Or is it purely cosmetic?

I guess I'll know tomorrow morning when Charlie Rose and Tavis Smiley either are or are not there....

[gplasky]

Originally Posted by PeteCress

Is there any way to verify that once they've been added to the pool?

I don't see anything in Disk Management or WHS' Console.

Go to a command prompt. Go to C:\fs
Type dir and you should get a listing of directories. These actually represent your drives. You can change directory into one of these and type chkdsk /f and when it is done it will tell you what size blocks it is using.

Or

Go to the Disk Defragmenter. Just use Analyze. NEVER RUN DISK DEFRAGMENTER ON WHS. Analyze will tell you what size blocks are being used also in addition to the fragmentation.

Gerry

[Skirge01]

Originally Posted by PeteCress

Thanks, I'll take you up on that after, as you say, attaining some basic level of competance.

Hopefully I didn't come across rudely. If so, my apologies. There'll definitely be plenty of people here to help out. WHS is quite popular around these parts.

My usual MO for things like this is to back everything up; put the backups in a drawer or someplace where I can't get to them too easiy; and then just sort of stumble in.... doing maybe 2-3 installs until I get it right.

Sounds really crude, but the 2-3 installs help cement the basics in what's left of my mind.

I'm normally the same way and don't really put much thought into installing an OS or building a computer. However, I knew how unique WHS was compared to all the other OS's I had previously installed and dealt with, so I did my homework ahead of time. I probably read for 6 months before I ever purchased a part for the server. I'm not suggesting anyone needs to do that, but simply that's how serious I took the WHS install and how badly I wanted to make sure I knew what I was doing (or, at least, *thought* I did).

[Skirge01]

Originally Posted by PeteCress

But the WHS install process reverted me to 20-280.

Maybe something to do with my having partitioned it, but not formatted the second partition?

Water over the dam... I'm sticking with 20.... and I note that the initial install is less than 5 - which, IMHO, is pretty good. I think the best I could do when trimming XP Pro for my itty-bitty laptop was 4.7 gigs.

I used a 750GB drive and currently have 8.59GB free on C:, which includes nearly 3GB of MovieTimes trailers, FlexRAID, Firefox, Arcsoft, CCCP, and many other programs not considered necessary--or even supported--in WHS. My WHS directory alone is just under 3GB. Needless to say, there's plenty of room with that 20GB.

[Skirge01]

Originally Posted by Taddeusz

But FlexRAID would still be susceptible to the very same bit rot that can prevent a RAID 5 array from being restored following a failure. FlexRAID is basically, sort of, RAID 5 for mixed size drives. Except that the parity is not spread across all drives as in RAID 5. You can't get around the bit rot though. No amount of redundancy can.

I hadn't heard of bit-rot until you mentioned it, so I did some quick reading (feel free to correct anything I *think* I now understand, BTW). I found this, which talks about three preventative things:

1. Scrubbing
2. ECC Ram
3. Checksumming

Unless I'm misunderstanding what's meant by "scrubbing", FlexRAID has a validation function, which I do run weekly. I have ECC Ram, so I should be good there, as well. I'm not doing any checksumming, but I think that may be overly cautious.

I also started reading this AVS thread, which brought up some good info, including this:

"In my experience, the best way to stop so-called bit rot is to refresh the data occasionally. That means moving it (copy to new/compare/delete original) or rewriting it."

Wouldn't WHS' drive balancing help to "refresh" the data every so often? Granted, there's really no easy way to know for sure what data was moved and when, but at least it's something, right? Also, with how frequently Sage is recording/deleting, quite a bit of my data is changing every few days.

That said, I'm using FlexRAID for non-critical data (my recordings), so should something be unable to be restored due to bit-rot, I'd still be able to restore everything else, which would significantly reduce my loss. My critical data is backed up using WHS' duplication feature, which automatically ensures that the data is written to two physically separate drives.

[Skirge01]

Originally Posted by gplasky

Go to the Disk Defragmenter. Just use Analyze. NEVER RUN DISK DEFRAGMENTER ON WHS. Analyze will tell you what size blocks are being used also in addition to the fragmentation.

Just to build on this, even more recent defrag utilities, which have supposedly been designed for WHS, have been causing issues (not the analyze piece, however). Perhaps some utilities out there are safe at this point, but be very cautious or, do as I'm doing and steer clear of defraggers in WHS entirely.

[PeteCress]

In SageTV.Properties, I see a pointer to something like "Backup copy of wiz.bin".

Right now I've got the actual Wiz.bin living in a folder under the pre-defined WHS share "Software".

I'd like to have it or a recent copy living somewhere outside of WHS, so if WHS bites the big one, at least I've got all my program schedule info and pointers to recordings.

Somebody who probably knows in MS's WHS forum says the best solution to keeping data that WHS doesn't know about is an extra physical drive that is not added to the pool.

I'll probably go that path.

But my question is "How often does that backup copy of Wiz.bin get refreshed?".

If it's every time SageTV starts (or stops...) then is seems more logical to point SageTV's prop for the backup to the new physical drive and just leave the actual Wiz.bin within the WHS pool - or even revert it to the default path in C:\Program Files\SageTV - where it seems like it would also be outside of WHS' drive pool.

Tangentially, I'm getting the impression that it's futile to image WHS' OS bco some sort of dynamic references to "Tombstones".

Have I got that part right? Seems counter-intuitive that an OS can't be imaged and the image restored when needed. OTOH, if files in the pool are continually being moved around to balance the physical discs, it makes some sense.

?

[gplasky]

Just use any backup program to schedule a backup for the the wiz.bin to a drive in the pool and have that folder duplicated. Or to an external drive attached to the WHS. Or to another share on another computer. There are so many different ways to do it. Use Microsoft's SyncToy to sync the file (or the whole directory) again, to the pool, external drive or a network share.

Gerry

[Skirge01]

Originally Posted by PeteCress

I'd like to have it or a recent copy living somewhere outside of WHS, so if WHS bites the big one, at least I've got all my program schedule info and pointers to recordings.

I'm using Cobian Backup. It took some doing to get the permissions right for the remote PC's, but it worked out fine. I do nightly incremental backups of SageTV (both client and server) and weekly full backups of the entire Sage folder on both. I keep those for a rolling 60 days. I also back up my FlexRAID config and HD Homerun config. These are also backed up to a duplicated share.

Somebody who probably knows in MS's WHS forum says the best solution to keeping data that WHS doesn't know about is an extra physical drive that is not added to the pool.

Depends how you look at it. While I wouldn't back up the OS drive because I believe what you do regarding the tombstones, there's no reason not to back up important files from the OS drive. After re-installing the OS following a failure of the C: drive, re-install the applications, then copy the important files back over.

Have I got that part right? Seems counter-intuitive that an OS can't be imaged and the image restored when needed. OTOH, if files in the pool are continually being moved around to balance the physical discs, it makes some sense.

This is one of the most frustrating and requested features (or lack thereof) for WHS. Supposedly, MS is listening an intends to implement it at some point in the future, but it could very well not be until the next version is released. But, from what I've read, the actual reason is quite logical when you look at it from THEIR perspective. You C: drive should only contain files and programs that WHS has installed itself, either via the OS install or via a plug-in or another part of the OS creating the file. That being the case, after you restore the OS using WHS' restore functionality, you should only need to re-install the missing apps and be ready to go. Personally, I haven't done this, so I don't have first-hand experience, but that's the impression I've gotten.