I'm not sure if I'm the only DB user here (everyone else seems to use Stablebit), but nevertheless I thought I'd post about my recent experience with it.
I built my server just over 2 years ago, and having read about the removal of DE from WHS2011 decided to go with a replacement. At the time Stablebit's solution seemed more 'beta' than DB so I went with the latter (and indeed I think DB was the first to get out of beta). I set it up with three 2TB drives and apart from the lack of VSS support preventing back-up of the pool, I just got on with using the server and forgot about it.
A few weeks ago DB reported that a drive was offline and it had gone into fault-tolerant mode. I was partially pleased about this because DB had proved its worth - loss of a drive but no loss of data (and yes I confirmed this was true). A reboot brought the drive back online, but then it seemed to want to take a break from service once a day. A few days later my SMART utility finally reduced the drive's health from 100% to 97% and CHKDSK found and corrected a bad sector. Nevertheless the temporary offline incidences continued so it was clear that the drive was no longer suitable for permanent data storage.
As it happened I was ready to expand my storage and had already purchased a few 4TB drives. So I set about replacing the sick drive and adding the others. Here I found the DB interface to be simple. Apart from the time it took (I guess not surprising for about 1.5TB of data), the operation to transfer the data was smooth and without issue, leaving my pool intact and separating the sick drive out ready to be removed. Similarly adding the new drives to the pool was simple. I was surprised to find that the pool was active the whole time so clients could access shared data without issue. The only problem was that client backup got disturbed during the process and I had to repair the backup store after the operation.
I created a few tickets with Division-M during the process to help me with a few things and the support has been excellent.
There are only a few gripes I have:
1) DB told me that after the sick drive had been removed there would still be data on it - the 'duplicated' files which didn't need to be removed in the process. However it recommended that I check the drive to ensure that there weren't any 'primary' files remaining. When I did this I could clearly see the duplicates, but also found what I thought were primaries. I decided to carefully cross-check my data and confirmed that it was all in the pool before formatting the drive (to keep as a secondary back-up because it still works). This was a bit time-consuming and I would have preferred if DB could have been more confident that it had transferred the data correctly.
2) Since adding the drives to the pool DB has been gradually filling them with data in it's balancing process. When I read some help notes online, it implied that this would only happen when I added new data to the pool (when it would choose emptier drives first). Maybe the help is out of data and this balancing is a more recent addition to DB.
3) DB has functions which search the pool to find files which have been marked for duplication but for which no duplicates exist, and duplicated files with no 'primaries'. These were great to use after the drive swap to give me confidence that all was well. The latter function did find some parentless duplicates, and when I checked them it appears that they are all duplicates of 'temp' files (e.g. from MS Office) which must have got duplicated before the application deleted them. It would have been good if I could have deleted these duplicates directly, but it seems that the only way to do this is to perform a pool repair function.