w3wilkes

This has been reported and the developer says it will be fixed in release 3.2.0.0

I've not seen anything like this. Hopefully the developer will get back to you with some assistance. Let us know what you find out.

A question best asked in a support ticket. https://support.division-m.com/hc/en-us/requests/new

12GB seems quite large. My total for the log folder is only 428MB. Your best shot for a quick response is to open a support ticket to ask Anthony.

1- You should release the license for DriveBender on your old server 2- Remove disks and install on new server 3- Install DB software 4- when you reboot after installing DB it should recognize the pool and all should be well 5- reregister your DB license on the new server

You should open a trouble ticket and ask the developer about the cbfs driver and if it has been tested and known to work or not with Server 2019. https://support.division-m.com/hc/en-us/requests/new

Have you opened a support ticket? https://support.division-m.com/hc/en-us/requests/new

Got a reply from Anthony. He said it's been reported by several users and he's working a fix for 3.2.0.0.

For some reason this periodically resets to a very bogus number. This time I have 14.34TB used of my 4TB pool! I've reopened a ticket.

I've closed the ticket. No trouble found in the logs. I manually went through and turned on duplication for each the sub-folders that didn't duplicate. New sub-folders duplicate as they should.

Problem solved. Anthony (DB) directed me to run HealthCheck on the pool and it fixed the pool utilization display discrepancy.

Don't know why I'm just noticing these things now that I've rebuilt my pool??

I recently got rid of my small (as in MB size) drives in my pool and replaced them with two 2TB 2.5" drives. These are plenty of space to hold all my backups and a DB duplicated music library. My music library is comprised of a root folder of "MP3 Music" with subfolders for each artist and album folders for each album under the albums artist. I use Synctoy to copy the library so that folder/file date and times are preserved rather than being stamped with the time the data was put on the pool drives. Part way through the copy I realized that I needed to turn on duplication for the main "MP3 Music" folder so I selected the main "MP3 Music" folder and said to duplicate the folder and all subfolders. So far so good, the remaining folders/files of the copy were duplicated in the pool as they were copied. The next day after the copy was complete I looked at my "MP3 Music" folder and found that the stuff copied before I turned on duplication still hadn't been duplicated. At this point I manually set duplication on for the main "MP3 Music" folder using the all subfolder to be included option. DB churned for a while, but did not duplicate the non duplicated stuff. I then went to each artist folder that still showed as not duplicated and set duplication for the artist folder. This works for all the album folders under each artist. It appears that DB can't handle duplication when there's more than some number of folders/files greater than some amount (in my case it was about 12,000 songs across many artists/albums that needed duplication). Or was the problem something to do with turning on duplication for a folder while subfolders/files were being created in the top level folder? I have open a support ticket.

I would suggest that you also open a support ticket, sometimes the devs miss requests in the forum. https://support.division-m.com/hc/en-us/requests/new

I would have thought that a reboot would have brought the drive back into the pool as long as it's still functional. In the case where you merged it as an existing DB pool drive I'm not sure what to do to clean up the dups. It would be good to open a support request. https://support.division-m.com/hc/en-us/requests/new