I have just bought a Drobo and mounted it with 4 x 1.5 TB. According to Drobo Dashboard, this gives me a total of 4.07 TB available for data.
When asked about sizing the volumes, I selected 4 TB (I made a try with 16 TB, but this was not worth the very long “Drobo boot up time”). This created two volumes of 4 TB each, we can call them “Drobo 1” and “Drobo 2”.
I assume these are two “logical” 4 TB volumes, sharing the same physical 4.07 TB available for data. When the total amount of data of these volumes is 90% of 4.07 TB I expect the Drobo to signal a red light and the Drobo Dashboard to give me a warning.
However, I actually wanted to make the whole Drobo encrypted with Truecrypt. Therefore I deleted the newly created partition on “Drobo 1” and encrypted the entire “device” (not the partition). Save the somewhat bad performance, the encrypted device seem to work as it should.
However, Drobo Dashboard is now only reporting the size of the “Drobo 2” volume, which it states has 3.99 TB free. I also don’t get any “blue lights” on the Drobo unit - although I’ve filled up the Truecrypt volume with about 1 TB. Therefore I wonder:
What happens when I’ve filled the Truecrypt volume (previously called “Drobo 1”) with 4 TB? Will Drobo recognize this and ask me to put in larger HD’s?
What happens when I’ve got 4 TB on the Truecrypt volume and start writing data on the un-encrypted Drobo 2 volume? Will Drobo think that Drobo 2 owns all the physical 4.06 TB, although it’s actually encrypted with Truecrypt, and owerwrite the data on the Truecrypt volume?
Ok then it’s the same issue as our KB article: Why aren’t all the partitions I created showing up in Drobo Dashboard after I upgraded to version 1.5.1?
We are sorry you are experiencing this problem. This issue is showing up when customers have created multiple partitions using a disk utility, such as Disk Utility (Mac), Disk Management (Windows) or another third-party utility. Most of the reports have been from customers upgrading from Drobo Dashboard version 1.2.4 or earlier. While we are investigating this situation, rest assured that it is purely cosmetic: the volumes still mount and are accessible. Please continue to check our support website and knowledge base for updates.
I exited the Drobo Dashboard, and you’re correct - I now get a couple of blue lights on the Drobo, very likely indicating the data I’ve put on the Truecrypt volume.
But after I installed Drobo Dashboard 1.2.4, the blue lights disappeared. The dashboard also doesn’t find the data on the Truecrypt volume. However, I did not use the link you sent, because I do not know how to install a .dmg file. Instead I used the following link: http://www.drobo.com/support/updates/dashboard/drobodashboardinstaller_1092_v1-2-4.exe
Should I try the .dmg file instead, and how do I install it?
Just for the records. It DID find lit up the blue lights with Drobo Dashboard 1.2.4. After waiting for a very long while, and it still didn’t show the correct usage within Drobo Dashboard.
However, I then found the new version 1.3.4 [1.251.20303] firmware and upgraded. When restaring the Drobo after upgrade, I got the blue storage lights about immediately and the Drobo Dashboard actually showed the the correct usage of the Truecrypt volume. Which some security minded people might find a bit fishy, especially since the Truecrypt volume wasn’t even mounted. I therefore guess there’s some kind of “file structure layer” with at least some kind of metainformation on what’s stored that the Drobo keeps track of. Which might, or might not, be used to lower the security of Truecrypt.
However, I don’t see how it could work in any other way if the Drobo should be able to know when it’s running out of physical diskspace.
But just to make things more interesting, after a few minutes the Drobo Dashboard stopped showing the correct space (=all space free) and the blue lights died. It might have been at about the same time as I mounted the Truecrypt volume, but I’m not sure.
Do not use full disk encryption with a Drobo. It will not work.
You have to create an un-encrypted file system, and then create a truecrypt volume inside a container file.
Yes, but if you encrypt a volume which is smaller that the amount of physical disk space - you will not run out of disk space. In this case I have encrypted a 4TB volume which should fit within the 4.07 TB of physical disk space.
I also used the option of “Quick Format”, which doesn’t “fill up” the volume with random data. Therefore the Drobo should (and do if I turn of the Drobo Dashboard) be able to detect how much disk space is left on my encrypted volume. If I had not selected Quick Format, I would expect Drobo to immediately give me the red signal for a full HD.
I know that Quick Format lowers the security, but this should be remedied to some extent by first creating an encrypted volume using Quick Format, then delete it, and recreate the encrypted volume without it.
Corrected a problem where a drive’s size was incorrectly reported to Drobo Dashboard
I installed firmware 1.3.5 and rebooted both the computer and the Drobo. It seemed to work for all of 30 seconds after starting up and finding the Drobo. Then the green lights died and the Drobo Dashboard (1.5.1) only showed the allocated space on the unencrypted volume again.
First, you should not be frightened by the obsolete claim that large partition sizes with take an inordinately long time to boot. T’ain’t true now, at least, if in fact it ever was. Take it from someone who has done it, you will be a lot better off if you resize your partition to 16TB now, before you fill up your Drobo with lots of stuff, because copying from one partition to another on the same machine is painfully slow.
Second, Full Disk Encryption packages vary in how they format the drive. Many will attempt to format and encrypt every sector on the disk before it is ever used, which will send Drobo into a slow down as it crosses the 95% utilization threshold. Some, including WinMagic’s SecureDoc, provide the option of only encrypting a sector with existing data, or the first time the sector is first used. Not only is that much faster, it doesn’t put the drive into slowdown.
Now, using the smart volumes concept, it is possible to allocate a volume that is smaller than the physical size of the drive. In that case, even those FDE systems that attempt to format the entire drive won’t go into slowdown.
Finally, I won’t bore you with the details, but I would recommend that you google “disk encryption theory” on Wikipedia. My recommended encryption solutions in descending order would be: (1) XTS-AES, in accordance with IEEE P-1610 and the recent draft of NIST SP 800-38E; (2) AES-256 with Cipher Block Chaining (CBC); and (3) Electronic Code Book mode (ECB). Absolutely Not Recommended would be any disk or media encryption solutions that use Output Feedback (OFB), Counter Mode (CTR), Galois Counter Mode (GCM), or Counter with CBC Mac (CCM), specially if used in conjunction with a system that encrypts the entire volume before data is written to it, because of the extreme ease with which it can be broken if a before and after copy can be made.