Christopher (Drashna)

No, it wouldn't move with it. You'd have it remain on the one drive, *and* show up on the new drive. However, with balancers like the "Ordered File Placement" balancer, it would help prevent that behavior from occurring.

Yes, it does look like that is "right". Though it *should* be "attrib -H -S D:\PoolPart.GUID /D". There should be no issues with doing this, that I'm aware of, but Alex may have input on that. And I don't think it will change it back, but I'm not certain. As for a better solution, I think FlexRAID may work better here. Less issues, I believe.

I would recommend resetting the permissions here. Specifically by going to the root of the DrivePool disk, and "replace child entries" option.

It depends. If you do a lot of WRITES, or the write speed is critical to you, then the feeder disk is a great option. However, if it's not important to you, then ... well it may not be worth it. Just remember, if you use a SSD, it will get thrashed. Also, you'll want two feeder disks if you're using duplication.

Very nice. And glad to hear that these are more stable for you. And responded to the tickets. Hopefully we can get SMART data working for you again.

Yup, basically that easy. ANd it won't recognize the "shares". you'd have to manually re-share the folders. But it will recognize the entire pool. And yes, deactivate the license on the WHS system, and activate it on the Win8 box.

Henning, Please use the newest beta version. http://dl.covecube.com/DrivePool/beta/download/StableBit.DrivePool_1.3.6.7577_BETA.wssx

Double check the "File Duplication" setting. It may be that some of the folders were set already. And if that was the case, then it may not be "inheriting" those settings properly. Also, run the "remeasure" option. If neither of these fix the issue, then please hit us up at http://stablebit.com/Contact/

I don't see a screen shot. And I'm not sure what you mean here.

Well, for StableBit .... the 2.x version has it's own remote control. So that's a plus to Windows 8. As for WHS2011, these are built in features but: Remote Access Website (to access files, and computers) Client Backup User management, streaming

Okay, yeah, that would be why duplication isn't working. It only sees one disk.

Otispresley is right. Since DrivePool is a file based solution, any one file must be smaller than the largest drive to be stored there. However, if the program you're using uses ZIP files, (or any other compressed file type) they usually have the option to break up the file into smaller parts. Suitable for downloading or transporting.

Client backups are fine. But by "roles", I mean anything installed by server management. Such as Windows Deployment Services, HyperV, etc.

That's partially my write up, yes. As for hacked, .... no, not really. It just shows access. A crawler bot will generate this, and *may* be doing so. As for checking to see if you've been hacked, check the "Security" log in the event viewer. That may indicate that better. But for the most part, no you haven't been hacked. However, if you are concerned about this, install an Antivirus program on the server. I recommend ESET NOD32, as it officially supports WHS (without having to buy the "enterprise level" versions).

@Doug, Damaged != SMART errors. Damaged means damaged sectors. @Kazooba, you can change DrivePool's behavior by chaging the balancer settings for Scanner. But I wouldn't remcommend it. As for allowing it to use the other disks... if you run "chkdsk /r" on these disks, it will repair the bad sectors (by remapping them). We don't do this automatically, because it means that you won't be able to recover data in that case.

Well, could you get tracing logs, so we can make sure it's not a DrivePool related issue? http://wiki.covecube.com/StableBit_DrivePool_Log_Collection Also, worst case, wiping the database may fix it (but that's a "nuclear" option )

Well, the easy way to recreate the database is to delete all the files for it.

I'm not seeing any instructions at all. Give me a day or two, and I'll see what I can do.

Didn't create or not starting? Also, could the Error Reports. http://wiki.covecube.com/StableBit_DrivePool_2.x_Error_Reports

Download the slight older version: http://dl.covecube.com/WssTroubleshoot/Release/download/Wss.Troubleshoot_1.0.0.165.exe

"Out". If you head to the download page, the 2.1.0.432 BETA build supports reparse points. https://stablebit.com/DrivePool/Download Change log: https://stablebit.com/DrivePool/ChangeLog?Platform=win And Alex has released a blog post about support for it as well: http://blog.covecube.com/2013/11/stablebit-drivepool-2-1-0-432-beta-reparse-points/ But no quota support, yet. And no VSS support. I talk to alex about this regularly, but it would be complicated at best. There is no documentation on how to implement it. At all. And even if we could, it may not be stable anyways.

We could probably put a "delete affected file" option here. Another suggestion we've had recently is to make Scanner "DrivePool" aware, and grab the duplicate file and basically write over it. It's an option. And I've passed it onto Alex. However, you don't need to delete the file to fix the bad sector. In fact, deleting it doesn't fix it at all. Specifically, any time you write to affected portion of the disk, the disk itself is supposed "fix" the issue by re-allocating it (hence the "Reallocated sector count" in SMART). And you can force the disk to identify the issue and fix it by running a "chkdsk /r" pass on the disk. The "/r" flag is specifically to identify and recover bad sectors. The reason we don't have an option for this is that Scanner isn't really "file aware" when it's doing the surface scan. It's checking sector by sector for sections that it cannot read. However, when you run the file recovery, it reads each and every sector of the affected files. It then attempts a number of "head placement strategies" to see if we can read the damaged sections and actually fully recover the affected files. So basically, the file recovery process is doing this already. We just don't "clean up" the damage sections on the disk. Seen number #1 But if you are seeing a growing number of damaged sectors, then ABSOLUTELY RMA IT. The reason is that under normal circumstances, you should never see damaged sectors. The disks internal error correction and SMART should identify these issues and fix them silently, before any "harm" is done to the disks. When you see damaged sectors, it means that the disk has failed to do this. While this may happen from time to time, if you're seeing this happen a lot, then there is likely something wrong with the disk. A custom disk threshold or a "rescan recently damaged disk more often" option may be a good idea. Again, NTFS and your disk are supposed to be doing this automatically. Once a damaged sector has been written to, which happens under normal usage (or when forced, such as a format, or chkdsk /r), the disk sees the damaged sector, and reallocates it to a spare good one. And it then should increase the "Reallocated sector count" value on the disk, I believe. But again, this should be happening automatically. The thing is, all this happens normally. Scanner is just making it obvious. That, and I believe that chkdsk is more concerned with reallocating the data, than it is with recovering it. Specifically, it just tries to read the data, and if it fails, it reallocates it. And at this point, you lose the data. As I said, we use a bunch of head placement strategies to try and read the data. I believe there are 20 "profiles" we use while attempting to read the affected data. But it only needs to read once. Once that's done, we save the recovered file. However, we don't clean up the disk, in case we do fail, or the recovered data is corrupted. That way, if you need to, you can run data recovery tools and intentionally save the file that way. I'm not 100% certain about all of this, but this topic has come up a lot lately, and I've talked with Alex extensively about this. Because this is a very complicated and sensitive topic. And a very, very important one.

The idea has been brought up before. I beleive Alex's answer was basically "No". It's a completely different OS, and would require rewriting everything from the ground up. As well as learning everything necessary for it. DrivePool relies a lot on built in Windows functionality/API. Which may not be there, or work the same on Linux. Though, as for moving the linux, most (if not all) linux distro's should be able to read NTFS just fine. That, and you can use gparted to convert to "ext3", aka the linux file system. Though with any disk editing/conversion, you should ALWAYS make a backup, just in case.

No, scanner does not change anything on the affected drive. At all. Ever. Specifically, we have a very specific "no writing" policy for scanner. The only exception is the file recovery process and the "fix file system" (but that's chkdsk). Normally, when the disk tries to write to those sectors (which naturally occurs), it will clear up the issue (by noting these are bad sectors and reallocating them to good sectors). As will manually running a "chkdsk /r" pass.

The duplication consistency isn't checking the files, it's checking the status, and making sure it's properly duplicated. However, it does go much more in depth when it does a full duplication pass (usually at night). And there isn't a way to do this manually. However I will flag this for Alex