Christopher (Drashna)

Unfortunately, this come up from time to time, especially on new versions. We usually try to report to false positive when we're notificed about it.

For the surface scan, StableBit Scanner doesn't do anything to fix/correct the unreadable sectors. You can clear the status, but the next scan, they will likely come back. That said, the only way to permanently clear the status is to write to the effected sectors. StableBit Scanner doesn't do this, as it prevents the ability to recover the data from the disk. However, the simplest (but definitely not "best") way to clear the status is to do a full format pass of the drive. This writes zeros to the entire drive, and may correct the issue. If this doesn't work, then you may want to consider replacing the drive (RMA it if it's under warranty)

You have to detach the drive, and reattach it, to move the cache.

You can get larger than that, but I wouldn't recommend anything about 64TBs, as NTFS cannot run CHKDSK passes on volumes larger than that.

I think you're looking for this: https://stablebit.com/Support/Scanner/2.X/Manual?Section=Disk Scanning Panel#Sector Map As for getting rid of the warnings: Don't. If these are unreadable sectors, they are exactly what they sound like: spots on the disk that StableBit Scanner was not able to read from, at all. (or at least, in a reasonably timely manner). This can sometimes happen if there are communication issues (such as a loose or bad cable), but if they consistently return, it indicates an issue. The best way to clear the status is writing to those sectors. StableBit Scanner isn't designed to do this, as it actively avoids writing to the disks. However, a full, non-quick format pass may correct these unreadable sectors.

The NVMe drive completely failed? If so, I'm sorry to hear that! As for the pool, yeah, once you remove the missing drive, it will remeasure the pool, and then run a duplication pass, reduplicating any of the data that needs it.

There isn't a good answer for this, and it varies from person to person. I would recommend x2, normally, and x3 for anything that is especially important and you cannot lose. (and copy that stuff elsewhere, such as to the cloud).

Previous Versions, aka shadowcopies aka System Restor use the "System Volume Information" folder to save a snapshot of the files. This happens only on the actual drives (not the pool drive), and counts as "other" data. You can disable this in the system properties, if you want, by running "SystemPropertiesProtection". You can disable and delete the "protection" for these drives.

Specifically, as long as the software isn't actively balancing or duplicating data, you should be okay with doing so. If the computer crashed/BSOD/etc, while the data was running balancing or duplication, then this could happen. In fact, that's exactly why we use the copytemp extension for these processes. So, that if the process is interupted for some reason, that you don't have a partial file left on the pool, effectively creating a corrupted copy. You should be okay to delete the file.

There isn't a way built in, but there is this user created guide:

Could you open a ticket at https://stablebit.com/Contact for this issue?

Should be fine, provided that the underlying disks can hold the VHD/etc files. Eg, the individual files are placed on the underlying disks.

Likely, yeah. Might be worth decreasing the number of threads, and upping the minimum download size, if you can. See if that helps.

This happens when the performance counters gets corrupted. This can be fixed by doing this: https://wiki.covecube.com/StableBit_DrivePool_Q2150495

You opened a ticket about this already (thank you!) andI've replied there, but I'll say this again: this is definitely not normal, and StableBit DrivePool should not format a disk, unless it is uninitialized or unformatted.

For this, you'd want to use the DrivePool (F:\). Just move the data from D: to F:, and then you should be fine. And no, you won't mess anything up by using E:\. However, you'd want to move the data to the hidden "poolPart.xxx" folder instead of to the root directory on the disk. And then remeasure after the data is moved/copied over. And we don't recommend doing this normally, but for the initial migration process, it should be fine. Also, if you want to hide the drive letter for the E:\ drive, you can do this: https://wiki.covecube.com/StableBit_DrivePool_Q4822624

The "/e" is a switch for lodctr. It's not the drive letter or anything like that. Specifically, it's specifying the disk performance counters, "PerfDisk". And glad to hear it!

Do you know what version worked properly for you last?

The simplest way to do that would be to have multiple pools, basically.

Yes, please open a ticket at https://stablebit.com/Contact And ideally, attach drive tracing logs of this in action: https://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection Also, it's very weird that Windows Defender would do this. as we do test with it. (well, it's hard not to). But issues with BitDefender... don't really surprise me. Also, in the meanwhile, it may be worth enabling the "bypass file system filters" option, as this should prevent the realtime scanner from being used when the pool reads the data from the underlying drives.

How did you copy the data over? If you copied the "PoolPart" folders directly, then that would cause this sort of behavior. There is some hidden metadata that is stored on the disk, and can't just be copied over. You need to add the disk to the pool, and migrate the data that way. Worst case, you should be able to do this: https://wiki.covecube.com/StableBit_DrivePool_F1655 While, this guide isn't strictly for your issue, it's close enough that it should work just fine.

It is from here, specifically: Unfortunately, there isn't a simple answer to this, nor a simple solution. It may help to disable "Previous Versions" on the drives, as this does show up as "other" data.

Yeah, the duplication creates multiple copies of the protected files, on other disks in the pool. These are 1:1 copies of the files, and will take up the same amount of space as the original.

By chance, was the drive in question formatted as ReFS? If so, then that may be the problem. Beginning of the year, Microsoft released a patch that causes ReFS volumes on removable storage to not mount. And unfortunately, StableBit CloudDrive mounts the drives as removable drives. If you can get an older install, without this patch, you should be able to access the data, at least.

You may need to do this: https://wiki.covecube.com/StableBit_DrivePool_Q2150495