Shane

The CRC error may be on the source drive or the destination drive (as described in the page I linked). At least it's letting you know there is a problem even if it can't fix it for you. Can you post a screenshot of the warning that DrivePool is displaying? "I'm also rather concerned at the suggestion to 'restore the file from a backup'. My understanding of duplication is that (and certainly that is the way I use it) it should prevent data loss from a single file/drive failure. Drivepool IS my backup!" Your understanding is correct, DrivePool does provides a RAID-like defense against data loss from drive failure(s), but there's a phrase in IT: "RAID is not Backup!" This is because there are many more ways to lose data than a drive dying. You could accidentally delete a file. A virus could deliberately delete a file (or all of them). A bug in a program or a fault in a controller could corrupt a file. Duplication does not protect against the first two and provides only limited protection against the third. There is also the very rare but not impossible chance of multiple drives dying simultaneously (not just by bad hardware but also by disaster such as fire or flood). This is why also having separate backups is important too.

Hi Kenny, yes that'd be the method to use. Based on the last time I did that, the process should be: Install the DrivePool and Scanner on the new system. Start them in trial mode. Make a record of your automatic balancing schedule (if any) and your Balancer plug-in settings (e.g. which Balancers you are using and what their priority and configurations are) on your old system. Make a record of your Scanner settings on your old system (if desired). Turn off automatic balancing (if any). Shut down both systems, pull your pool drives from the old system and put them in the new system, then start the systems back up. All your pool's content, balancing settings, duplication settings and placement rules should be there. Redo your Balancer plug-in settings on the new system. Turn back on automatic balancing (if any). Configure your Scanner settings on your new system as desired. Once you're happy with everything, transfer the licenses.

Let's see if I have this right: B is your old pool with all your stuff in it, and you want to keep its various per-folder duplication settings in the new pool. A is your new pool of SSDs, empty, and you want to use it as cache for your stuff via the Optimizer balancer, without any duplication. H is the new pool you created, added A and B to it, found the stuff in B didn't show up in H, you want that to happen, and you haven't put any files in H pool yet. If so, then: Tricky but it's doable thanks to DrivePool's file placement and per-folder duplication features being able to see (in-situ parts of) a super-pool as its own folder tree in the selected sub-pool with its own settings for the latter. And if that doesn't make sense yet then don't worry about it, it'll become clear. Simple way that'll probably take a very long time but should be safe (in the sense that it doesn't mess with poolparts): Temporarily remove A pool from H pool. Run this command to recreate B pool's folder structure in H pool: robocopy b:\ h:\ /e /dcopy:dat /xf * /xd "$RECYCLE.BIN" "System Volume Information" ".covefs" /r:1 /w:1 The reason we're doing this is so we can see all the folders in the next step. I'm assuming here that you do NOT have any symbolic links, special access controls or other NTFS clever stuff here. If you do, customise as needed. EDIT: Or maybe 'un-clever' your pool B first and 're-clever' pool H after the entire way is complete. In the DrivePool GUI select pool B, then select Manage Pool -> File protection -> Folder duplication... You should see pool H "within" pool B; here is where you manually copy B pool's per-folder duplication settings for H pool. For example: B pool: documents x2 criticaldocs x4 H pool: documents x1 -> x2 criticaldocs x1 -> x4 music x1 -> x3 music x3 Move your files from B pool's folder tree to H pool's folder tree. This will take ages because Windows will think they're on different physical drives even though they're not, and if you're using Explorer you'll have to do so in chunks no bigger than what Windows believes is the free space available on the target pool (I'd suggest chunks no bigger than the free space available on the physical drive with the most free space). That should (eventually) be it; your stuff will now all show up in pool H but it will be duplicated across the drives of pool B in accordance with your preferences there. Now you can re-add A pool to H pool and configure H pool's SSD Optimizer to use it as cache. Alternate way that should be much quicker - unless you make a mistake, because it's messing with poolparts: USE AT OWN RISK. Edit: For example, I'm assuming here that you do NOT have any symbolic links, special access controls or other NTFS clever stuff here. If you do, customise as needed. You may want to 'un-clever' your B pool before you use this way and then 're-clever' your H pool afterwards. Do NOT do this at night, because we want to avoid any risk of tripping over DrivePool's nightly background duplication check. Make a record of all your per-folder duplication settings in B pool. Temporarily remove A pool from H pool. In the DrivePool GUI select pool B and turn off its automatic balancing, then select pool H and turn off its automatic balancing. In the DrivePool GUI select pool B. Now select Manage Pool -> Performance -> Real-time duplication and make sure it is TICKED. Now select Manage Pool -> File protection -> Folder duplication... you should see pool H "within" pool B. Click on it, then Change its duplication level to be the same as the number of drives in pool B. Now select Manage Pool -> Performance -> Real-time duplication again and make sure it is NOT ticked any more. So every drive in pool B should have a hidden poolpart folder in its top directory and now thanks to the previous step each of those should itself have a hidden poolpart folder inside - the latter are the poolparts for pool H. So in each drive, drag your stuff - not any Windows or CoveFS stuff - from the former to the latter. Do NOT drag any folders named "$RECYCLE.BIN", "System Volume Information" or ".covefs". So if you had: x:\PoolPart.long-string-of-hexadecimals\ <-- this should be B pool's. -> $RECYCLE.BIN -> documents -> pictures -> PoolPart.different-long-string-of-hexadecimals\ <-- this should be H pool's. -> System Volume Information -> videos You would drag only "documents", "pictures" and "videos" into the PoolPart.different-long-string-of-hexadecimals folder. Confirm that all your stuff is now showing up in pool H. Open a command prompt as an administrator and run these two commands: dpcmd reset-duplication-cache b: dpcmd reset-duplication-cache h: In the DrivePool GUI select pool H, then select Manage Pool -> File protection -> Folder duplication..., make sure all duplication is off (fix it to off if needed). In the DrivePool GUI select pool B, then: select Manage Pool -> File protection -> Folder duplication..., recreate from the record you made earlier. select Manage Pool -> Performance -> Real-time duplication and make sure it is TICKED again ONLY IF you normally use real-time duplication. That should be it; your stuff will now all show up in pool H but it will be duplicated across the drives of pool B in accordance with your preferences there. Now you can turn back on automatic balancing (if you use it) for pools B and H, re-add A pool to H pool and configure H pool's SSD Optimizer to use it as cache. Whew.

You might find this link useful? https://community.covecube.com/index.php?/topic/5810-ntfs-permissions-and-drivepool/ It includes instructions on how to reset ownership and permissions back to the Windows/DrivePool defaults if the built-in methods don't work.

When browsing the physical drives, are you using the options to show both hidden and protected system files/folders? In-use poolpart folders are (or should be) set to hidden, ex-poolpart folders are (or should) not, but if Windows has done a chkdsk repair there may be files/folders set to system.

CRC error indicates a problem reading from / writing to a physical drive (you may find this link helpful); that drive may be going bad and you may need to remove it from the pool (if you do so, I'd recommend ticking "Force damaged file removal"). If DrivePool encountered the error while attempting to create a duplicate of a new/updated file you may need to restore the file from a backup. If DrivePool encountered the error while checking the consistency of an existing duplication, you'll need to identify which is the bad copy and remove it (the file and/or the drive) so that DrivePool can then re-duplicate from the good copy.

Hi, do you still need help with this or did Stablebit get back in contact with you?

It looks like the markers for the real-time placement limiters show the active limits; unless/until your "SSD" drives actually hit that 90% the "Archive" drives won't be receiving any files in real-time (so they have the marker at zero).

DrivePool uses the drive(s) you select to create a pool (virtual drive) that can use all of the (available) space of those selected drive(s). It doesn't import existing files, it just uses the free space; you have to manually move any files you want put in the new pool. So in your example, you have 9 HDDs and 2 SSDs. You created a Pool drive A that uses the available space of the 9 HDDs, and a Pool drive B that uses the available space of the 2 SSDs. Any existing files on those HDDs and SSDs remain where they are, outside the Pool drives. If you then create a Pool drive C using the available space of the A and B... it still only uses the available space of those drives, and the existing files in A and B remain where they are. If you look in one of the physical drives, say a HDD and let's call it G, you would find the hidden folder structure where DrivePool actually keeps its files, for example: G:\Poolpart.unique_string_associated_with_Pool_A\files_and_folders_that_are_actually_in_Pool_A <-- the bit in italics is the hidden folder for pool A Note that depending on how you've set up your duplication for A or B, the hidden folder for C might not show up inside the hidden folder for A or B in all of the physical drives, but it would exist in at least one of those drives and you would see it if you looked for hidden folders in Pool A itself, e.g. A:\Poolpart.unique_string_associated_with_Pool_C\files_and_folders_that_are_actually_in_Pool_C Each pool also has its own individual balancing and duplication settings; e.g. if you told A to dupe everything x3, and you told B to dupe everything x2, and you told C to dupe everything x2, then a file placed in C would - because it's made from A and B - end up using space in both A and B and so in turn use space in 3 drives of A and 2 drives of B. I hope this helps and isn't confusing! The important part is that a pool shares the available space of the drives (whether physical drives or pool drives) used to create it; it doesn't show any files placed directly in those drives (unless you start mucking with the hidden structures of those drives).

@Christopher (Drashna) Can you please elaborate on this - I'm guessing it's not a choice StableBit would prefer to make? I'd also suggest that it seems like the kind of change that should be officially announced in the forums sooner rather than later (also inb4 inevitable confusion of some users over "Google Drive" vs "Google Cloud Storage") and that some kind of warning message should be implemented in the CloudDrive product itself for those who have (or are adding) Google Drive as a provider. Edit: there is a warning message as of the 1.2.6.1706 beta. I need to read the notes more carefully. Thanks to msq for pointing this out and providing screenshots below.

Where are you getting that from?

I'd suggest searching for "unraid" in the forums here, as I've seen posts about people moving in the other direction - unraid to drivepool - after encountering problems with the former. Maybe run them side by side for a while, or at least be prepared for teething issues? In any case, best of luck!

Hi! You can use VSS-based backup methods to snapshot the physical drives that form the pool instead of the pool itself, though you may end up with redundant copies of files if you are using DrivePool's duplication. If you just want the ability to restore a recent version of a file, you may wish to look into (if you are using Windows 10/11 Pro) the built-in Windows File History utility as it can take regular snapshots (e.g. hourly). For non-VSS backup options, I use FreeFilesync to backup my pool (with versioning) to another machine; it can use but does not require VSS (except to optionally backup files that are in an open state). However I don't know how you would avoid a full initial backup with it.

What kind of error are you getting? I've just test and am able to download and install it from the Stablebit.com website.

That would indeed be a nice addition! In the meantime, if you can access "C:\ProgramData\StableBit DrivePool\Service\Logs\Service\" and open the corresponding day's log file, search for "missing pool part" and the line should include the missing pool part's identifier string; the corresponding hidden PoolPart.identifier folder will be on the drive that dropped out (if there are multiple entries with different identifiers, then multiple drives dropped out).

What sort of information are you wanting?

Yes, if you click Remove on the dying drive then it will automatically move everything (in the pool) that's on that drive to the other drives (in the pool). You may or may not wish to choose the option of "Force damaged drive removal (unreadable files will be left on the disk)." This will help if the drive has damaged files that can't be read. However, since you are using SnapRaid, you should instead be incorporating its instructions to safely transfer the files without messing up your parity (Disclaimer: I'm not great with SnapRaid, please double-check this): (turn off DrivePool balancing/placement if you're using it - which you probably aren't using if you're using SnapRaid) (stop DrivePool service) copy files from good Drive2 to good Drive3 check with diff, if good (identified as copies) proceed with a sync and continue to next step delete files on good Drive2 run a sync copy files from failing Drive1 to good Drive2 check with diff, if good (identified as copies) proceed with a sync and continue to next step delete files on failing Drive1 run a sync might as well take the failing Drive1 out of the machine at this point - run a secure erase on it if you need/want to - but remember to follow the SnapRaid procedure for removing a data disk from the array (start DrivePool service) (remove the "missing" Drive1) (might need to do a Manage Pool -> Re-measure if DrivePool doesn't do it automatically) (turn on DrivePool balancing/placement if you're using it - which you probably aren't using if you're using SnapRaid) You can still use Remove on a drive containing unduplicated files; it will still move them to another drive. DrivePool duplication, if enabled, is like RAID1 in that it ensures that duplicated files exist on two or more drives (so that if one drive dies unexpectedly you haven't lost any of the duplicated files that were on it as they will also be on at least one other drive). 2x duplication does use 2x the space of course, and so on. You can turn it on for the entire pool or customise it for specific folders.

If the drive's failing but stiil currently readable, then you could just tell DrivePool to Remove it and it will evacuate the data file by file to the rest of the drives in your pool (usually the one(s) with the most free space). If you're wanting to manually move the content as you describe (e.g. because you're using SnapRaid or because you want it done ASAP and don't have duplication), then as long as you turn off any Balancing and Placement, and stop the StableBit DrivePool service you can safely move* content between the poolparts so long as the internal structure is kept the same (e.g. don't change "pathX\fileY" in "Drive1:\PoolPart1342343\pathX\fileY" to "Drive2:\PoolPart324343\pathX\fileY"). Once you're done you can then restart the service, Remove the drive you manually emptied, and then turn back on any Balancing and Placement. *Note: for a failing disk with no duplication, instead of doing a "direct" move, I would copy the content to the destination and verify the copies before I deleted any content from the source. This minimises writes to the suspect disk while I'm getting data from it. "Also, the drives are SnapRaided, would it be safer to copy everything off and hope everything is in tact data wise, or restore from the parity drive ?" See the SnapRaid FAQ for the "100% safe way to proceed": https://www.snapraid.it/faq#move

If you are looking for a list of forum admins, then from the community.covecobe.com main page click Browse -> Staff. Alex and Christopher are the StableBit staff/admins, while Shane (myself) and saitoh183 are volunteer moderators. You can message any of them from the above page. I'd suggest Christopher first for general official responses/statements, myself if you just want some help re something on the forum? You can also contact StableBit re product sales/issues/feedback/development or the like via the Contact form.

As the old thread explains, DrivePool uses *.copytemp files in the process of balancing/duplicating files; if DrivePool is interrupted (e.g. power outage) during balancing/duplicating then both the original file and the temporary file.copytemp will remain. You can thus safely delete any *.copytemp files without losing data if DrivePool is not currently balancing or duplicating when you do so, and doing so will free up space occupied by the pool. (technically, a copytemp file from a previous balancing/duplication would be safe to delete during a current one, but as there's no easy way to distinguish between such it is best to wait until the current one completes)

The error message is not "there isn't enough space". The error message is "Make sure that you have enough disk space in order to satisfy your file placements rules and that they're not conflicting with other balancing settings" (emphasis mine). So since you have plenty of free space the problem is likely to be a conflict with other balancing settings, and in this case I suspect the SSD Optimizer. If you don't mind your File Placement rule over-riding the SSD Optimizer, try UN-ticking "File placement rules respect real-time file placement limits set by the balancing plug-ins." Edit: P.S. I would also not recommend a file placement rule that says to keep files on the same disk(s) that your SSD Optimizer has marked as "SSD" as the former would conflict with the latter wanting to empty files from there.

It might be a conflict between the file placement rules and the SSD Optimizer, as both do real-time placement. You may need to experiment with what you have (un)ticked in the File placement settings. Another option would be to have sub-pools for your cache disks and archive disks, so that you can have the file placement rules only apply to files as they move onto the archive disks.

You may need to tick "Balancing plug-ins respect file placement rules" in the Balancing Settings section. If you have duplication enabled, you will need to select the appropriate number of disks for a file placement rule (e.g. 2x duplication -> two disks).

If they're offline due to collision that suggests that somehow they've ended up with the same "unique" disk ID (a serial number assigned to a drive when initialised by Windows). Normally such collisions only happen when cloning a disk. ( @Christopher (Drashna) I can't imagine DrivePool having any need to change a physical disk's ID - any ideas what could cause this? Windows? ) You can use the Windows Disk Management utility and the DISKPART tool from an Administrator command prompt to view the ID. Find the disk numbers in the former, then use SELECT DISK number followed by UNIQUEID DISK in the latter, to select each disk in the pool in turn and view their IDs. They should be in the form of a long dash-separated hexadecimal string. The pool itself uses an eight character hex string. If you find two of your disks in the pool have the same ID, you can change one of them via selecting it (as above) and using UNIQUEID DISK ID=newstring command where newstring is a string chosen by you in the same format (e.g. just use the same string but change one of the characters); restart the computer afterwards. Be very careful here that you change only the ID of the particular disk you want. If you don't find two disks with the same ID then I would recommend opening a support ticket with StableBit. Regardless, your data should still be intact in the hidden poolpart folders on each disk and could be moved to a new pool if the old one can't be restored.

If the balance ratio slider for the Z: pool is set to 100% it should be balancing upon any discrepancy; if that is so set but not doing so, try un-ticking the "Or if at least this much data needs to be moved" box?