Shane

While files and folders in a pool will still show their size (and also their "size on disk") as if they were not duplicated, DrivePool calculates the total, used and free space on the basis of the actual physical drives' total, used and free space; it does not attempt to predict space on the basis of duplication (e.g. that if you have x2 duplication on the entire pool you'll of course be using x2 as much space for each file). This is because of the problem of it being impossible to predict post-duplication free space when using per-folder duplication.

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.

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)

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.

Depends on what you mean by clone (and presuming the drive lasts long enough to clone everything on it).
If you're cloning the whole drive, then you'll want to stop the drivepool service while both are connected or clone it on a different machine so you don't confuse drivepool (and then Remove the old drive from the pool after you've disconnected the old drive).
If you're adding the new drive to the pool then manually copying/moving the content from the old poolpart folder to the new one, you'll want to stop the drivepool service or at least turn off balancing/placement while you're doing that (and then Remove the old drive from the pool after you've disconnected the old drive).
If you're just Adding the new drive to the pool then Removing the old drive from the pool, letting DrivePool handle moving everything (perhaps with the option to handle damaged drives ticked), then you don't need to stop the service, though this is slower than the above methods (unless the old drive had Duplication enabled in which case you can use the option to re-duplicate later which makes it much faster at the cost of temporarily lowering your duplication).

DrivePool does not automatically remove empty folders from poolparts during balancing (basically for redundancy reasons; some pool metadata is stored as AD streams attached to the folders and the "space cost" of this is normally very low).
The upshot is that so long as the "abracadabra" folder tree is showing 0 bytes (as an administrator) and does not contain any hidden system folders (e.g. $recycle.bin or system volume information) then it can be safely removed manually while the DrivePool service is stopped; the only thing you'd "lose" is some extra redundancy.
 

If the content I want to put into the pool is already on one of the drives (about to be) in the pool, I prefer to (add the drive and) manually move the content into the poolpart. As you noted, it's almost instant.
One thing I do to reduce any risk of accidentally conflicting files or folders across poolparts is to create a unique folder to move the content into; e.g. if I have a pool "P:\" then - after I've stopped the service - I create a unique folder in the poolpart (e.g. "D:\poolpart.xyz\123" where there wasn't previously a "P:\123") and move what I want into that unique folder - then I can start the service back up and remeasure, and any further moving can be done via the pool rather than the poolpart; I don't even have to wait for the remeasure to finish).

Just delete the old folders and remove the letters. Don't format the drives.
DrivePool stores a pool's files inside a hidden "PoolPart.UID" folder (where each UID is a unique, dashed alphanumeric string) in each drive that's part of the pool, so formatting any such drive would erase that drive's hidden folder and any data in it.

Based on my own experiences, neither. Likely it means the drive's own firmware found something wrong (thus the S.M.A.R.T. flag) and then dealt with the problem itself, it's just that Scanner noticed the warning inbetween detection and resolution.
You might find further info in the logs (C:\ProgramData\StableBit Scanner\Service\Logs), or if you enable Scanner's email notifications and it happens again the email would mention which particular S.M.A.R.T. warning/error occurred.
As I use both duplication and nightly backups I'd just double-check that those are on and wouldn't worry about it; I'd only consider replacing the drive if the issue kept happening (more) often or became a permanent error rather than a temporary warning. YMMV.

Windows only supports drive letters A through Z.
However, it isn't necessary for a drive (other than the boot, system and pagefile drive, and perhaps CD/DVD drives and similar) to have a letter; drives can instead be accessed by mounting them as folders in another drive (e.g. C:\Array\Drive27, C:\Array\Drive28, etc) and furthermore itself DrivePool can have drives form part of a pool without being lettered or mounted at all.
To add/remove drive letters or mount drives as folders in other drives, use Windows Disk Management: right-click a volume and click Change Drive Letters and Paths...
Late edit for future readers: DON'T mount them as folders inside the pool drive itself, nor inside a poolpart folder. That risks a recursive loop, which would be bad.

DrivePool's duplication is similar to RAID in that, when enabled, it can protect against one or more drive failures (see this recent thread where I explain that further as well as backup practices).
But the short answer is that if one of your drives failed (assuming you hadn't enabled duplication) you'd lose whatever was on that particular drive; the rest of your pool would remain intact - e.g. if you had song1.flac only on drive A and song2.flac only on drive B in your pool, and drive A failed, song1.flac would be lost and song2.flac would be kept.
Regarding buying a HDD - it seems like you want/need as little latency and as much speed as possible when working? So I'd keep the HDD separate from your pool of SSDs (maybe in its own pool if you plan to expand) and set up a scheduled automatic backup (whether that's a robocopy script, freefilesync mirror, veeam agent, etc) to happen while you sleep. Your mileage may vary of course.

You may find this thread useful.

The service handles things like balancing and statistics; detecting pooled disks happens at the kernel/driver level.
Note that in DrivePool 2.x each hidden PoolPart folder has a unique extension and associated metadata identifier (even removing and immediately re-adding the same disk will result in a different one); because SnapRAID's parity calculations rely on paths remaining the same you should use the PoolPart folders (e.g. "d:\PoolPart.6cbd4f77-9511-4356-a6b3-2ce26ba79d10") as SnapRAID's data disk mount points rather than the root folders (e.g. "d:\") so that you can update the appropriate data disk mount point in the snapraid config file when you replace a drive to avoid needing a rebuild.
Presuming the above use of poolparts as data disk mount points is being done:
Pause SnapRAID scheduling (if you've set anything up).
  Add the new drive to the pool.
  Stop the DrivePool service.
  Rename the "PoolPart" section of the old disk's hidden poolpart folder so it stops being an active poolpart folder (e.g. to "oldpart") but optionally leave its extension unchanged to make it easier in case you need to revert.
  Copy the content (except protected system folders, e.g. "System Volume Information", which you should have set as excluded in SnapRAID) of the old disk's hidden poolpart into the new disk's hidden poolpart, then update the data disk mount point, then verify. See https://www.snapraid.it/faq#repdatadisk If step 5 worked out, then you can delete the old disk's hidden poolpart and continue.
  Start the DrivePool service. The old drive should be detected as "missing" and then you should remove it from the pool.
  In the DrivePool GUI, choose Manage Pool -> Re-measure... to ensure it is accounting for your manual movement of content.
  Resume SnapRAID scheduling (if you've set anything up). P.S. Regarding multiple content list files in your SnapRAID config, keep in mind that due to DrivePool this means that - for example - "d:\poolpart.1\snapraid.content" and "e:\poolpart.2\snapraid.content", where "d:" and "e:" are disks in the same pool, are effectively the same file on the same disk; either keep content list files outside of the pool (e.g. "d:\snapraid.content" and "e:\snapraid.content") or use different filenames (e.g. "d:\poolpart.1\snapraid.content1" and "e:\poolpart.2\snapraid.content2").

If drivepool has duplicates available on other drives to replace damaged files that are detected and removed by chkdsk then drivepool will do so when it next does a consistency check (which you can also manually trigger: Settings -> Troubleshooting -> Recheck duplication).

Not that I know of. You could suggest it via the https://stablebit.com/Contact form?

That's basically what DrivePool does, and the pool drive can be shared over the network, so it sounds like it would be suitable for you!

Unless the card does something very very weird, just make sure it's going to treat them as individual drives rather than an actual RAID array and DrivePool should find and recognise them.

Unless the card does something very very weird, just make sure it's going to treat them as individual drives rather than an actual RAID array and DrivePool should find and recognise them.

If you uninstall DrivePool, any existing pools will retain their content and be automatically re-detected when you reinstall DrivePool. Their duplication levels should be kept, but you may need to recreate any custom balancing/rules you had for them.

@srcrist @Thronic Both of you have made valid points concerning the pros/cons of CloudDrive, rClone and cloud storage.
However, unless specific information is still needed, I suggest this topic has been "sufficiently covered".

I think I see what you're getting at; you need to take advantage of DrivePool's ability to nest pools.
I.e. you would create a Pool A using your local drive(s), a Pool B using your cloud drive(s), create a third Pool C using Pools A and B as "drives" and turn on duplication for all of Pool C.
The result is that anything stored in Pool C will always have at least one copy locally (kept in a hidden folder in Pool A) and one copy in the cloud (kept in a hidden folder in Pool B).
If you also wanted to have multiple copies locally you would then turn on duplication for Pool A, or at least for the Pool C's hidden folder in Pool A.
And so on and so forth.

Due to the way DrivePool works (each physical drive added to the pool gains a hidden poolpart folder that DrivePool uses to form the virtual pool drive), if you're willing to use the drives your files are already on to form your pool then you can directly move your existing files into the pool with a few precautions.
Otherwise you would need to copy them into the pool at the usual speeds involved.

The poolpart folders do not need to inherit their permissions from their respective volume roots (though they default to doing so on a newly created pool using previously unformatted drives). The SYSTEM account must have full control of the poolpart folder, subfolders and files. The Administrators account is recommended to have full control of same. For more details, I have just created this thread.

The poolpart folders do not need to inherit their permissions from their respective volume roots (though they default to doing so on a newly created pool using previously unformatted drives). The SYSTEM account must have full control of the poolpart folder, subfolders and files. The Administrators account is recommended to have full control of same. For more details, I have just created this thread.

Yes, DrivePool allows you to use pools as disks for other pools.
For example if you had physical disks A, B, C, D you could create a pool E from disks A and B, a pool F from disk C, and then a pool G from disk D and pools E and F. Note however that any given disk or pool can only be directly part of one bigger pool at a time (so you can't "add" disk A directly to both F and G).
Keep in mind that exactly like physical disks added to a pool, pools used as disks don't share their own contents with the new pool, only their free space (with the new pool being a hidden folder in the file system of the contributing pool/disk). So any content you place in the example pool G would not see any content you placed (outside of its hidden folder) into disk D or pools E or F.
For a more specific and relevant example, say you had drives A, B and C on one computer and drives D, E and F on a second computer. You could create a pool G of the first computer's disks, a pool H of the second computer's disks, and a cloud I formed from G and H. Then you'd be able to move your files into the cloud I while independently controlling duplication on each of the two computers by adjusting G or H appropriately.