Shane

If you mean Microsoft's cipher /w, It's safe in the sense that it won't harm a pool. However, it will not zero/random all of the free space in a pool that occupies multiple disks unless you run it on each of those disks directly rather than the pool (as cipher /w operates via writing to a temporary file until the target disk is full, and drivepool will return "full" once that file fills the first disk to which it is being written in the pool).
You might wish to try something like CyLog's FillDisk instead (that writes smaller and smaller files until the target is full), though disclaimer I have not extensively tested FillDisk with DrivePool (and in any case both programs may still leave very small amounts of data on the target).

I heard back from Gillware.  They want $1200 AND another drive that's at least 20 TB.  And they can only "guarantee" that they'll be able to recover around 80% of the disk.
JFC.  It's like they think the drive has been at the bottom of the sea for the past year.  I was thinking $400 tops.
I may never again go anywhere near diskpart.  If I had known things were going to be this expensive, I would've tried using something like EaseUS first, on my own.
Ughughughughughugh.

I'm still restoring the pool, which'll take another couple of days (no word yet from Gillware), but I got off my duff and took the Sabrent apart.  I have to say that it's really impressive on the inside, with almost everything some manner of metal.  Only the front doors and a handful of other parts are plastic.  Unpopulated, Sabrent says that it weighs 17.8 lbs, so it would definitely kill you if someone dropped it on your head, even drive-less.
The PSU is a very cute 3.5" x 5" x 1.25" device that should be up to the task since it only has to have enough oomph for 10 drives along with the two 120mm "Runda" RS1225L 12L fans.  As you can see from the label, it's a 399.6W "Mean Well" EPP-400-12 unit when cooled adequately.  Since a normal 3.5 drive only consumes around 9.5W at load, that's only 95W needed for the drives, with the rest for the fans and the supporting PCB.
So, assuming the PSU isn't outright lying, I don't think that's the issue.  I checked mine for obvious problems, like expanding or leaking caps, but didn't see anything.  The caps themselves look to be of pretty decent quality and the bottom circuit board appears clean.  The unit has what looks to be a rheostat, but I have no idea what it controls.
If I had to take a very wild guess, I would say there's something amiss with the backplane, as that seems to be a common source of consternation with low(er)-grade server-style boxes, like the Norco.  It is interesting that I only started seeing drive dropouts once I had populated all ten bays, so maybe it works fine with only 8 or 9 bays running.
So far, the two Terras are running just fine.  I'm praying to all sorts of gods that it remains so.

I believe currently the only way is to download everything to local and use the converter tool come with CloudDrive to convert it to other mountable format.

Oh, hrrmmm, interesting.  It looks like FreeFileSync did the job, but its UI looks like it was done by a madman, so I might try Robocopy next time.  That fileclasses link is EXTREMELY helpful.
A bit more on the pool reconstruction front.  I really needed more than six drive bays to work with, so I bloodied a credit card and bought another Terra.  FFS mirrored everything on the old pool to the three new Seagates seemingly fine.  Oh, but before that, the Seagates long formatted successfully, so I'm considering them good to go.
I'm currently long formatting three of the old pool drives, which'll take another 24 hours.  Once that's done, I'll fire-up the second Terra with old pool drives and copy everything over from them to the drives that I'm in the process of long formatting (presuming they pass).
Gillware has the drive.  I stressed to my contact that the drive should be fine electronically and mechanically, so they shouldn't have to take it apart.  I'm HOPING this will lower the cost of the recovery substantially.  You would think restoring everything from a simple diskpart clean should be a cakewalk for a professional recovery service, but we'll see.
Incidentally, I was looking over Terramaster's line of products and they are all-in on NAS devices, with their flagship product supporting 24 drives.  I wish they would offer a 10- or even 8-bay DAS box, but then you're back to needing a beefy PSU.  I still intend to take apart the Sabrent assuming it's not a nightmare to do so.
That's currently all the news that's fit to print.  More to come!

Once you've obtained your own API key from Google, the file to edit is C:\ProgramData\StableBit CloudDrive\ProviderSettings.json
I also suggest making a backup copy of that file before you make any changes to it.
You may then need to restart clouddrive. Per Christopher's post, "The safest option would be to detach the drive, change API keys, and re-attach. However, you *should* be able to just re-authorize the drive after changing the API keys."
I suspect 350 Mbps is the best you'll get. 

Rossmann said they couldn't do anything with the drive, which REALLY surprised me, so they referred me to Gillware Data Recovery.  I need to talk to them first before sending the drive in to make sure the attempt will be a reasonable sum, which I'll try to do tomorrow.  I guess the moral of the story is not to futz around with diskpart unless you know for damn sure you know what you're doing.
I received the Terramaster.  It looks like a typical grey internal drive cage, just a little wider and without any mounting points.  It uses screw-in drive sleds, unlike the Sabrent, which is a PITA, but c'est la vie.  However, it also came with some paper-like inserts that go in-between the drives and the bottom of the sleds, which I've never seen.  The boxed instructions don't say why they're required and the online product guide doesn't even mention them, so I can only guess their purpose (electrical insulators?).  Bizarre.  It also doesn't have an internal PSU as such, but came with a laptop-style 12V barrel plug brick power converter.  Unlike the Sabrent, the drives sit vertically, which makes me a bit uncomfortable (I might lay it on its side).  There is only one USB-C connector.
There has been some talk on the Terramaster forums about people needing a powered USB hub with this unit.  I don't know why this would be required when directly attached to the USB-C port on a motherboard, but maybe that's been my problem all along.  If so, I'll consider slitting my wrists later.
I'm in the process of long-formatting three 18 TB Seagate Exos simultaneously.  If that passes, I'll continue trying to rebuild the pool.  This is my last attempt at doing so.  If the formats fail, I'm giving-up, at least for awhile.  Maybe in the far-flung future I'll get a proper tower with a 10,000 watt PSU and stuff it with drives, but I really, REALLY hope the Terramaster comes through.  I have confirmed that Windows recognizes all six drives, but the Sabrent did the same until I started encountering those drive dropouts, so longevity will determine the winner.
More to come!

I haven't heard from Rossmann yet.  If I don't get a reply by Wednesday, I'll voice call them.
I did order the 6-bay Terramaster, which should be here tomorrow.  If/when I'm satisfied it's running as advertised, I'll rebuild the pool and copy over what I can.  Assuming everything goes smoothly (har har), I'll reinstall everything and restore from config backups, which I've been holding-off on doing until I can figure things out.
I really, REALLY hope the Terramaster "just works".  Since it only accepts six drives, the power demand should be a lot less than the Sabrent.  I'd still like to disassemble the Sabrent to see what sort of PSU it's using.  I'm 99.9% sure it's something custom, but you never know until you actually eyeball things.
I'll report back in a few days.  Wish me luck.

I think I'm gonna give up on having a pool.  Maybe a computer.  I was trying to clear that 18 TB Exos out using diskpart.  This Exos has the label of ST1800NM.  Another 20 GB Exos that I had bought a few months ago has the label ST2000NM.
I was tired, bleary-eyed, more than a little frustrated with all these problems, wasn't thinking 100% straight, and selected the ST2000NM in diskpart, and cleaned it.
Problem is this drive had gigabytes of data that was critical to the pool.  GIGABYTES.  I still can't believe I made such a simple, rookie, and yet devastating mistake.
My God.
I don't know if any of the file table can be salvaged, as I just did a simple "clean" and not a "clean all", but I've got a recovery request into Rossmann Repair Group to see if they can do anything with it.  I know there are some tools in the wild that I could probably run myself on the drive, but I don't trust myself to do much of anything atm.
I should never have thrown money at an AM5 system.  I also probably should've stayed away from the Sabrent and anything like it.  Instead, I should've done what any sane person would've done and assembled a proven AM4 or Intel platform in a full tower and attached the drives directly to the motherboard.  Yeah, the cable management would've been a nightmare, but literally anything would be better than this.  My goal of staving-off obsolescence as much as possible has instead kicked me in the teeth while I was already lying prone in a ditch.
If, by some miracle, Rossmann is able to recover the data, I'm going to take a long and hard look at my PC building strategy.  Hell, maybe I'll throw money at a prebuilt or one of those cute HDMI-enabled NUCs that're all the rage.  I just know that I'm exhausted and am done with all of this, at least for the time being.

I think that's not currently possible. It does sound useful and you might wish to submit a feature request (e.g. perhaps "when setting per-folder duplication, can we please also be able to set whether duplication for a folder is real-time or scheduled") to see if it's feasible?

I'm sure you figured it out already... From the images you posted, it just looks like a simple change is needed.
The pool called ORICO BOX is fine as is. The one in the first image is not correct. You should have:
A pool that has 12TB1 & 12TB2 with NO duplication set. (lets give it drive letter W:)
A pool called ORICO BOX with NO duplication set. (with the assorted drives) (Lets call it drive letter X:)
Now, drive W: essentially has 24TB of storage since anything written to W: will only be saved to ONE of the two drives. You can set the balancing plugin to make them fill up equally with new data.

Drive X: essentially has 28TB of storage since anything written to X: will only be saved to ONE of the five drives.
 
At this point, you make ANOTHER new pool, Lets call it Z:  In it, put Drivepool W: and Drivepool X:. Set the duplication settings to 2X for the entire pool. Remember, you are only setting Drivepool Z: to 2X duplication, no other drivepools need changed.
 
What this should do (if I didn't make a dumb typo): Any file written to drive Z: will have one copy stored on either 12TB1 OR 12TB2, AND a duplicate copy will be stored on ONE of the five Orico Box drives. You must read & write your files on drive Z: to make this magic happen.  Draw it out as a flowchart on paper and it is much easier to visualise.
 

FWIW, digging through Microsoft's documentation, I found these two entries in the file system protocols specification:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/2d3333fe-fc98-4a6f-98a2-4bb805aff407
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/98860416-1caf-4c80-a9ab-8d61e1ccf5a5
In short, if a file system cannot provide a file ID that is both unique within a given volume and stable until deleted, then it must set the field to either zero (indicating the file system does not support file IDs) or maxint (indicating the file system cannot given a particular file a unique ID) as per the specification.

MitchC, first of all thankyou for posting this! My (early a.m.) thoughts:
(summarised) "DrivePool does not properly notify the Windows FileSystem Watcher API of changes to files and folders in a Pool." If so, this is certainly a bug that needs fixing. Indicating "I changed a file" when what actually happened was "I read a file" could be bad or even crippling for any cohabiting software that needs to respond to changes (as per your example of Visual Studio), as could neglecting to say "this folder changed" when a file/folder inside it is changed.
(summarised) "DrivePool isn't keeping FileID identifiers persistent across reboots, moves or renames." Huh. Confirmed, and as I understand it the latter two should be persistent @Christopher (Drashna)? However, attaining persistence across reboots might be tricky given a FileID is only intended to be unique within a volume while a DrivePool file can at any time exist across multiple volumes due to duplication and move between volumes due to balancing and drive replacement. Furthermore as Microsoft itself states "File IDs are not guaranteed to be unique over time, because file systems are free to reuse them". I.e. software should not be relying solely on these over time, especially not backup/sync software! If OneDrive is actually relying on it so much that files are disappearing or swapping content then that would seem to be an own-goal by Microsoft. Digging further, it also appears that FileID identifiers (at least for NTFS) are not actually guaranteed to be collision-free (it's just astronomically improbable in the new 64+64bit format as opposed to the old but apparently still in use 16+48bit format).
(quote) "the FileID numbers given out by DrivePool are incremental and very low.  This means when they do reset you almost certainly will get collisions with former numbers." Ouch. That's a good point. Any suggestions for mitigation until a permanent solution can be found? Perhaps initialising DrivePool's FileID counter using the system clock instead of initialising it to zero, e.g. at 100ns increments (FILETIME) even only an hour's uptime could give us a collision gap of roughly thirty-six billion?
(quote) "I would avoid any file backup/synchronization tools and DrivePool drives (if possible)." I disagree; rather, I would opine that any backup/synchronization tool that relies solely on FileID for comparisons should be discarded (if possible); a metric that's not reliable over time should ipso facto not be trusted by software that needs to be reliable over time. EDIT 2024-10-22: However, as MitchC has pointed out, determining whether your tools are using FileID can be difficult and the risk of finding out the hard way is substantial.
Incidentally, on the subject of file hashing I recommend ensuring Manage Pool -> Performance -> Read striping is un-ticked as I've found intermittent hashing errors in a few (not all) third-party tools when this is enabled; I don't know why this happens (maybe low-level disk calls that aren't compatible with non-physical volumes?) but disabling read-striping removes the problem and I've found the performance hit is minor.

The "Other" and "Unusable" sizes displayed in the DrivePool GUI are often a source of confusion for new users. Please feel free to use this topic to ask questions about them if the following explanation doesn't help.
 
Unduplicated: the total size of the files in your pool that aren't duplicated (i.e. exists on only one disk in the pool). If you think this should be zero and it isn't, check whether you have folder duplication turned off for one or more of your folders (e.g. in version 2.x, via Pool Options -> File Protection -> Folder Duplication).
 
Duplicated: the total size of the files in your pool that are duplicated (i.e. kept on more than one disk in the pool; a 3GB file on two disks is counted as 6GB of duplicated space in the pool, since that's how much is "used up").
 
Other: the total size of the files that are on your pooled disks but not in your pool and all the standard filesystem metadata and overhead that takes up space on a formatted drive. For example, the hidden protected system folder "System Volume Information" created by Windows will report a size of zero even if you are using an Administrator account, despite possibly being many gigabytes in size (at least if you are using the built-in Explorer; other apps such as JAM's TreeSize may show the correct amount).
 
Unusable for duplication: the amount of space that can't be used to duplicate your files, because of a combination of the different sizes of your pooled drives, the different sizes of your files in the pool and the space consumed by the "Other" stuff. DrivePool minimises this as best it can, based on the settings and priorities of your Balancers.
 
More in-depth explanations can also be found elsewhere in the forums and on the Covecube blog at http://blog.covecube.com/
Details about "Other" space, as well as the bar graphs for the drives, are discussed here: http://blog.covecube.com/2013/05/stablebit-drivepool-2-0-0-230-beta/

Pretty much as VapechiK says. Here's a how-to list based on your screenshot at the top of this topic:
Create a folder, e.g. called "mounts" or "disks" or whatever, in the root of any physical drive that ISN'T your drivepool and IS going to be always present: You might use your boot drive, e.g. c:\mounts You might use a data drive that's always plugged in, e.g. x:\mounts (where "x" is the letter of that drive) Create empty sub-folders inside the folder you created, one for each drive you plan to "hide" (remove the drive letter of): I suggest a naming scheme that makes it easy to know which sub-folder is related to which drive. You might use the drive's serial number, e.g. c:\mounts\12345 You might have a labeller and put your own labels on the actual drives then use that for the name, e.g. c:\mounts\501 Open up Windows Disk Management and for each of the drives: Remove any existing drive letters and mount paths Add a mount path to the matching empty sub-folder you created above. Reboot the PC (doesn't have to be done straight away but will clear up any old file locks etc). That's it. The drives should now still show up in Everything, as sub-folders within the folder you created, and in a normal file explorer window the sub-folder icons should gain a small curved arrow in the bottom-left corner as if they were shortcuts.
P.S. And speaking of shortcuts I'm now off on a road trip or four, so access is going to be intermittent at best for the next week.

This is mainly an informational post. This is concerning Windows 10.
I have 13 drives pooled and i have every power management function set so as to not allow Windows to control power or in any way shut down the drives or anything else. I do not allow anything on my server to sleep either. I received a security update from Windows about 5 days ago.
After the update I began daily to receive notices that my drives were disconnected. 
Shortly after any of those notices (within 2 minutes) I received a notice that all drives have been reconnected. There was never any errors resulting from whatever triggered the notices.
I decided to check and I found that one of my USB controllers had its power control status changed. I changed it back to not allowing Windows to control its power and I have not received any notices since. 
I do not know for sure but I am 99% sure that the Windows update toggled that one controller's power control status to allow windows to turn it off when not being used.
I cannot be 100% sure that I have had it always turned off but, until the update, I received none of the notices I started receiving after the update. 
I suggest, if anyone starts receiving weird notices about several drives becoming lost from the pool, that you check the power management status of your drives. Sometimes Windows updates are just not able to resist changing things. They also introduce gremlins. You just have to be careful to not feed them after midnight and under no circumstances should you get an infested computer wet.   

Future reference for anyone else who runs into this issue, I fixed it with the following settings:
Under file placement settings, uncheck "unless drive is being emptied", but leave "file placement rules respect real-time..." checked. This is important because the SSD optimizer empties the drive, which is why it was overriding file placement rules.
In file placement rules, Folder A should have the desired archive drive checked as well as the SSD cache drive.

DrivePool does not use encryption (that's CloudDrive). However, in the event that you have used Windows Bitlocker to encrypt the physical drives on which your pool is stored then you will need to ensure you have those key(s) saved (which Bitlocker would have prompted you to do during the initial encryption process).

DrivePool does not use encryption (that's CloudDrive). However, in the event that you have used Windows Bitlocker to encrypt the physical drives on which your pool is stored then you will need to ensure you have those key(s) saved (which Bitlocker would have prompted you to do during the initial encryption process).

hello
1.  make note of or take screenshots of your DrivePool settings if you have changed them from the default settings in any way.  if you take SSs step 2 is important.  DP saves your pool data in Alternate Data Streams on the drives themselves but doesn't save any customized balancer/file placement rules etc.  from Manage Pool ^ Balancing... under the pie chart in the GUI.  also take note of Manage Pool ^ Performance > settings as well.
2.  make sure all your user data (i.e. all docs, pics, DLs, etc.) from your C:\Users\[your user name]\ have been saved/backed up elsewhere.
3.  yes deactivate your license - cogwheel with downpointing arrow in upper right corner/Manage license/deactivate.  in fact you should do this for all licensed 3rd party software on your machine.  if you are reinstalling on the EXACT same hardware it *shouldn't* much matter but better safe than hassled later.
4.  power OFF machine, and unplug/detach ALL drives EXCEPT your win10 drive from the mobo and any USB ports.  IOWs ONLY the win10 boot drive where you want to clean install win11 is attached.
5.  install windoze 11 and update to latest version, all new windows update security patches, etc etc.
6.  DL and install the latest version of DP from https://stablebit.com/DrivePool/Download and reactivate the license.
7.  power OFF your machine and reconnect your DrivePool drives and power ON.
8.  in the DP GUI Manage Pool ^ Balancing... ensure all is reconfigured and set up as it was before the reinstall.  SAVE.  Manage Pool ^ Performance > as well.  if it were me, i would reboot here.
9.  it is important to remeasure the pool before using it normally.  Manage Pool > Remeasure... Remeasure.
*NOTE*  if you never messed with the settings and all was left at default before, steps 1 and 8 can probably be omitted/ignored.  my own pool is fairly customized, so i included them as part of the procedure I would follow.
cheers

A final, I hope, follow-up to this. I have fixed the problems by simply going to the OS level and going to each drive and making "Everyone" the owner, with full rights, to each of the PoolPart... directories on the drives. That seems to have cleared everything up and the duplicating functioning is restored. 
I probably made this more trouble than it needed to be but I plead age and poor health that influenced my decisions to the more complicated side.  I lost a few files but at least i did not need to rebuild my entire pool.
I wish there was a tool available that will fix this kind of issue automagically but doing it manually is not too bad as long as the correct choice is made early on. Unfortunately some of my early decisions led me down the wrong path so it took me several times longer than it should have.
Again, I plead old brain syndrome.

Folks, thank all for the ideas. I am not neglecting them but I have some health issues that make it very hard for me to do much of anything for a while. I will try the more promising ones as my health permits but it will take some time. From operation and the lack of errors during writing/reading it seems that I am in no danger except duplication won't work. I can live with that for a while.
Keep the ideas coming and, maybe, I can get this mess fixed and report back which tools worked for me.
I am making one pass through my pool where I remove a drive from the pool, run full diagnosis and file system diagnosis on that drive then I re-add it back to the pool. When completed that will assure that there are no underlying drive problems and I can proceed from there.
Thanks to all who tried to help this old man.  

Google Drive support is being discontinued in StableBit CloudDrive.
Please make sure to back up all of your data on any existing Google Drive cloud drives to a different location as soon as possible. Google Drive cloud drives will not be accessible after May 15, 2024.  
FAQ
Q: What does this mean? Do I have to do anything with the data on my existing cloud drives that are using the Google Drive storage provider?
A: Yes, you do need to take action in order to continue to have access to your data stored on Google Drive. You need to make a copy of all of the data on your Google Drive cloud drives to another location by May 15, 2024.
Q: What happens after Google Drive support is discontinued in StableBit CloudDrive? What happens to any data that is still remaining on my drives?
A: Your Google Drive based cloud drives will become inaccessible after May 15, 2024. Therefore, any data on those drives will also be inaccessible. It will technically not be deleted, as it will still continue to be stored on Google Drive. But because StableBit CloudDrive will not have access to it, you will not be able to mount your drives using the app.
Q: Is there any way to continue using Google Drive with StableBit CloudDrive after the discontinue date?
A: You can, in theory, specify your own API keys in our ProviderSettings.json file and continue to use the provider beyond the discontinue date, but this is not recommended for a few reasons:
Google Drive is being discontinued because of reliability issues with the service. Continuing to use it puts your data at risk, and is therefore not recommended. We will not be actively updating the Google Drive storage provider in order to keep it compatible with any changes Google makes to their APIs in the future. Therefore, you may lose access to the drive because of some future breaking change that Google makes. Q: What happens if I don't backup my data in time? Is there any way to access it after the discontinue date?
A: Yes. Follow the instructions here: 
Alternatively, it's also possible to download your entire CloudPart folder from Google Drive. The CloudPart folder represents all of your cloud drive data. You can then run our conversion tool to convert this data to a format that you can mount locally using the Local Disk storage provider.
The conversion tool is located here: C:\Program Files\StableBit\CloudDrive\Tools\Convert\CloudDrive.Convert.exe
The steps to do this would be:
Log in to your Google Drive web interface ( https://drive.google.com/ ). Find the CloudPart... folder that you would like to recover under the root "StableBit CloudDrive" folder. Each CloudPart folder represents a cloud drive, identified by a unique number (UID). Download the entire CloudPart folder (from the Google Drive web interface, click the three dots to the right of the folder name and click Download). This download may consist of multiple files, so make sure to get them all. Decompress the downloaded file(s) to the same location (e.g. G:\CloudPart-1ddb5a50-cae2-456a-a017-b48c254088b3) Run our conversion tool from the command line like so:

CloudDrive.Convert.exe GoogleDriveToLocalDisk G:\CloudPart-1ddb5a50-cae2-456a-a017-b48c254088b3

After the conversion, the folder will be renamed to: G:\StableBit CloudDrive Data (1e6884be-b748-43db-a78c-a4a2c720ceef)
  After the conversion completes, open StableBit CloudDrive and connect the Local Disk provider to the parent folder where the converted CloudPart folder is stored. For example, If your cloud part is stored in G:\StableBit CloudDrive Data (1e6884be-b748-43db-a78c-a4a2c720ceef), connect your Local Disk provider to G:\ (you can also use the three dots (...) to connect to any sub-folder, if necessary). You will now see your Google Drive listed as a local cloud drive, and you can attach it just like any other cloud drive. If you need further assistance with this, feel free to get in touch with technical support, and we will do our best to help out: https://stablebit.com/Contact
 
Q: Why is Google Drive being discontinued?
A: Over the years we've seen a lot of data consistency issues with Google Drive (spontaneously duplicating chunks, disappearing chunks, chunks reverting to a previous historic state, and service outages), some of which were publicized: https://www.zdnet.com/article/google-heres-what-caused-sundays-big-outage
For that last one, we actually had to put in an in-app warning cautioning people against the use of Google Drive because of these issues.
Recently, due to a change in policy, Google is forcing all third-party apps (that are using a permissive scope) to undergo another reverification process. For the reasons mentioned above, we have chosen not to pursue this reverification process and are thus discontinuing Google Drive support in StableBit CloudDrive.
We do apologize for the great inconvenience that this is causing everyone, and we will aim not to repeat this in the future with other providers. Had we originally known how problematic this provider would be, we would have never added it in the first place.
To this end, in the coming months, we will be refocusing StableBit CloudDrive to work with robust object-based storage providers such as Amazon S3 and the like, which more closely align with the original design goals for the app.
If you have any further questions not covered in this FAQ, please feel free to reach out to us and we will do our best to help out: https://stablebit.com/Contact
Thank you for your continued support, we do appreciate it.

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

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.