Shane

Hmm. I vaguely recall this has come up before. Basically the "total" (unduplicated + duplicated + free remaining) in DrivePool's gui is based on the file sizes rather than the size they take up on the disk, which aren't necessarily the same due to the way NTFS works. DrivePool is still (as you can see from the top left of the tooltip) aware of the actual size of the physical drive. Aha, found it: TLDR the DrivePool uses "file size" rather than "size on disk" for some of its calculations, and this is reflected in the GUI. If you want DrivePool to recalculate these just in case, you c

If I had make a wild guess, it's possible that the Windows 7 Backup is assuming the destination is a physical drive and attempting to use VSS or special NTFS metadata operations which aren't supported by DrivePool. For whatever it's worth, I'm using Veeam for my own system image backups and haven't encountered that issue.

gtaus is correct: if chkdsk unmounts the drive, Drivepool will notice the drive is missing and change the pool to read-only until the drive is remounted at which point the drive will merge back into the pool and the pool will become writeable again it is unlikely but if chkdsk goes wrong and effectively formats the drive, the pool will need to be told that the drive is permanently gone and whatever was only on that drive will be lost it is also unlikely but if chkdsk goes wrong and mangles the drive contents but the poolpart folder itself is intact enough for drivepool to r

I'd recommend adding the new drives or creating a new pool with them, and then moving the contents inside each old poolpart to the new poolpart - minus any system folders - rather than attempting to moving the poolparts themselves. Trying the latter may result in Windows complaining about the hidden system folder ("System Volume Information") that Windows creates within the poolpart folder. Alternatively, if you've got any spare USB ports, you could use USB drive dock(s) to help perform the migration? Preferably USB3, because USB2 would take a lot longer. Especially, don't try to cut

The OS writes files by going (approximately) "create/open entry for file on drive's index, stream data to file from program, write details (e.g. blocks used so far) to drive's index, repeat previous two steps until program says it's done or the program says it's encountered an error or the drive runs out of room or insert-other-condition-here, write final details in the index and close entry for file". Or in even simpler terms: at the system level all files are written one block at a time, no matter how many blocks they'll eventually involve. Now a workaround for programs that deal with f

I haven't tested whether it will rebalance in that way; hopefully it doesn't, as that would cause the same sort of problem as above, but if it does there is the option to set OFP to only place new files and leave existing files where they are.

Ah, I see. Ordered File Placement overrides the normal "write new files to the disk with the most free space" rule. You've got Ordered File Placement set to "fill each drive until there is only 1% or 5 GB free on it" and you've still got 5.25 GB free on the first disk (and 5.44 GB on the next). So it's going to try to write files to the first disk until it's got less than 5 GB free. And since the file you're trying to write is 100 GB, it can't fit so DrivePool can't hit the limit that will let it switch to the next drive (which in this case wouln't be able to fit it either). Note th

Can you post your Settings tab?

You have to tick "Balancing plug-ins respect file placement rules" and un-tick "Unless a drive is being emptied" in the "File placement settings" category on the "General" tab of the Balancing settings.

It would run out of space before it could finish, and the program would get an error. However, normally the automatic balancing defaults include the Prevent Drive Overfill balancer being set to detect any drive with less than 100 GB free and emptying it into other drives until there is at least 200 GB free. So that situation is unlikely to happen unless you've changed the relevant defaults or you don't have enough space left on every drive in the pool.

If you haven't already, I'd start with turning off automatic balancing and copying each drive to a backup.

That's disturbing. Do you have a separate backup? Can you contact Stablebit and ask them to investigate?

Hmm. I suspect the folder is still actually named PoolPart.guid at the system level but there is now a hidden system file named desktop.ini inside the folder that is telling Windows Explorer to show the name as Contacts instead (because that's a thing in Windows). These hidden system files can sometimes accidentally get brought along with visible files during moves or copies by users (because Windows). If that's the case, deleting or renaming that file should fix the problem (I suggest doing this at the pool drive level rather than the physical drive level). You might need to go into Wind

It seems good at first glance, though I'm not sure about the scheduled task part. How would you do that? Direct movement between the poolparts, or using File Placement to tell LargePool that any file the task moves to an 'Old' folder is to be balanced into the CloudPool half of the LargePool?

In order: Pools become read-only while a drive is missing (or if a trial version expires) until that drive is returned or formally removed. This may be a problem for your plan (see bullet point four). Drivepool never splits files. It may split folders. If you try to remove a drive from the pool via the GUI, it will attempt to first move the files on that drive to a different drive (if any) in the pool. If duplication is turned on, duplicated folders will be read-only for the duration. If you remove a drive from the pool any other way, the pool becomes read-only until