2. RAID Setup and Testing
The T5_R5-eSUF RAID box came with some management software which correctly displayed the five 1.5 TB WD Caviar Green drives I put in the case (Figure 2-1).
Figure 2-1. RAID hardware detected.
A couple of clicks later and the RAID 5 set was created (Figure 2-2). The five drive array uses one for redundancy (essentially a check-sum of the other 4 drives) which leaves 6 TB (4x1.5TB) left for protected data storage.
Figure 2-2. RAID 5 set created.
The Disk Utility also showed the 6TB of space as a single volume (Figure 2-3). At this point, the volume still needed to be formatted, which went as expected.
Figure 2-3. RAID 5 set correctly shows up as a 6TB drive in the Disk Utility.
Next, the RAID was connected to the TC via the eSATA port on the RAID box using the same SATA to eSATA cable used for the initial external drive testing in the TC (Figure 2-4). When everything was powered on at first, nothing showed up in the Airport Utility. After restarting the RAID box with the eSATA plugged in, then restarting the TC, the drive was properly detected (Figure 2-5).
Figure 2-4. RAID Capsule connected for the first time.
Figure 2-5. Formatted RAID shows up in the Airport Utility.
Just to be sure, a quick test was done to make sure data could be read from and written to the RAID set via a share from the TC (Figure 2-6). At first, everything seemed to work fine, but within a few minutes of inactivity, the RAID box somehow lost connection with the TC. This hadn't been a problem with other eSATA devices connected to the TC, so it seemed like a problem with the RAID box quad interface. If the RAID box was turned off and back on, everything worked fine again, without having to restart the TC. But after a little bit of inactivity, the connection was lost again. When the RAID box was accessed via Firewire or USB, this problem did not occur, however. After some conversations with the DatOptic tech support (who were quite helpful), the consensus was that the eSATA controller on the quad interface bridge wasn't compatible with whatever sleep/wake activity that was going on in the TC SATA controller. They suggested bypassing the bridge and connecting directly to the SATA connector on the TC logic board (Figure 2-7). Sure enough, this fixed the issue, but I was kind of annoyed since I wanted to have Firewire access as well. The tech support guy offered to send me (for free) an eSATA bracket so I could switch between the quad interface and the eSATA pass-through just by unplugging and plugging the SATA cable inside the RAID box between the two interfaces. This was a slightly more acceptable solution, which I improved upon later (this will be discussed in part 4). At the time though, I had to wait for that part, so I carried on with the rest of the setup and modifications.
Figure 2-6. File transfer in progress.
Figure 2-7. RAID box and TC connected directly via SATA cable.
There's a good chance that things could work fine with the RAID set formatted via Disk Utility, but to avoid potential headaches down the road, the RAID set was re-formatted using the Airport Utility (Figure 2-8). This went mostly as expected, except that the formatted volume only had 2 TB of space according to the Airport Utility (Figure 2-9).
Figure 2-8. Formatting the RAID volume with Airport Utility.
Figure 2-9. RAID formatted via Airport Utility. Note incorrect capacity of 2 TB reported for the disk.
The RAID box was connected to a Mac via Firewire and the formatting was checked in the Disk Utility (Figure 2-10). As expected, the "APconfig" and "APswap" partitions were also created.
Figure 2-10. Volume is indeed only 2 TB. "APconfig" and "APswap" partitions were also created.
At this point, it seemed that the 2 TB volume might be an artificial limit the TC put on drive during formatting, so repartitioning the drive with the Disk Utility should probably overcome that limitation (Figure 2-11). For my purposes, I wanted several different partitions anyway. One would be a 3 TB volume to be used as a Time Machine backup for the 1 TB drive in my iMac. I also wanted to have two partitions dedicated to clone backups that would be accessed via Firewire when needed and a final partition for backing up other data I have like homemade DVD disc images and digital tape backups. In addition to those four partitions, I wanted to be sure to keep the "APconfig" and "APswap" partitions in place. As it turned out, those two partitions could not be modified anyway. Another thing I found out was that you can't resize and rename a partition at the same time for some reason. Once all the partitions were properly sized and named, the partitioning was applied and after just a short wait, everything was set up the way I wanted (Figure 2-12).
Figure 2-11. Repartitioning the RAID set.
Figure 2-12. Repartitioned RAID set.
Another issue cropped up when the RAID set was reattached to the time capsule. Instead of the Time Machine volume showing up as "Time Capsule" in the TC shares, it showed up as "Data" (Figure 2-13). Some people might be able to let this slide, but I couldn't, so the share was renamed using the Airport Utility (Figure 2-14). Note also that the Airport Utility reports the disk sizes in TiB, whereas the Disk Utility reports TB (though both use the unit name "TB").
Figure 2-13. First shared partition mysteriously renamed to "Data".
Figure 2-14. Renamed "Data" share back to "Time Capsule".
When the renaming was applied, the name change persisted (Figure 2-15), however I noted that the total volume capacity was incorrectly reported as 2.0 TB (TiB really). This was a bit of a concern, but reattaching via Firewire and checking in the Disk Utility showed that all the partitions were still in tact and properly sized. Additionally, I copied about 2.5 TB of data to the 3 TB partition, then reconnected to the TC, mounted that share and copied some additional data just to be sure there wasn't some addressing issue that limited usable space to 2 TiB. This took some time, but worked without a hitch. The 2 TiB "limit" is still a bit of a mystery to me, but it doesn't seem to be an actual problem.
Figure 2-15. Share rename persisted. Total capacity still reported incorrectly.
Two more tests needed to be completed before moving on. First was to confirm the RAID shares were valid Time Machine targets (Figure 2-16) and to test the Time Machine backup (Figure 2-17). This went smoothly, albeit slowly (800 GB of data backed up over AFP takes some time). Lastly, cloning (using CCC) while the RAID box was attached via Firewire was tested and also completed without incident.
Figure 2-16. All shared partitions show up as viable Time Machine backup targets.
Figure 2-17. First backup to RAID Capsule.
Figure 2-18. Cloned hard drive via Firewire 800 connection.
Continue to Part 3: TC Modding
[Part 1: TC Take Apart and Testing] [Part 2: RAID setup and testing] [Part 3: TC Modding] [Part 4: RAID Modding and Final Assembly]
