Subsubtitle: When you write a backup software, make sure you understand the capabilities of the file system you’re copying from.
Since September 2013 I have been a more or less happy user of the Drobo File Transporter private cloud. The idea seemed and still seems perfect:
You buy two File Transporters and connect them to the internet in two different places. On each of your computers you get a „Dropbox-like“ folder that syncs to all of your computers and is even accessible from your iPhone or iPad. But its size is only limited by the size of hard disks you provide for no monthly fee. It’s a redundant backup system with the ease-of-use of Dropbox!
Alas, it’s not perfect. In the early days, the backup software was very CPU intensive but that got fixed eventually. Then followed a few months of honeymoon when the two Transporters just worked. And then, they suddenly started to run full. First the 500 Gb disk I had, then the 1 Tb disk. And I had only backed up 300 Gb.
I contacted the File Transporter support. (Don’t bother trying to activate your activate your Transporter account at https://support.filetransporter.com/activate. That never worked.) And I met support hell.
I was asked to perform the good old „Have you tried switching it off and on again?“ trick. That didn’t help. I had to fill out a long questionnaire about the kinds of disks I had connected, the File Transporter firmware version etc. I was asked to submit the full File Transporter log files.
By then, a full week had passed. The result: I was kindly informed that apparently my disks were full and I would need to switch them for bigger ones.
Obviously, I refused. The case got escalated. I was asked for screenshots of the management website and the Finder window that showed the amount of data I had backed up. I guess these established that I was speaking the truth here so … the case got escalated.
22 days after my original support request I receive an e-mail from 3rd level support. He asks me to send in the log files again. Something wasn’t right with the old ones apparently. At this point, my patience had run out, let alone my confidence that I was receiving support at all and not some form of online occupational therapy.
So I debugged the issue myself. If you still care, or come here via Google, this is it:
Do not backup iMovie 10 libraries to Drobo File Transporters.
As of Software/Firmware version 3.0.21 the iMovie library will fill your entire disk.
The explanation: The File Transporters format the disks with the ext2fs file system internally. I mounted them on my Mac and started to look for my backups.. I compared the size of the backups to the size of the original folders and quickly narrowed the problem down to the iMovie library.
The iMovie library folder contains a symbolic link „.fcpcache“ that links back to its parent, the iMovie library. I have no idea why it does that. It certainly seems unusual but it is just as certainly not forbidden to do that.
The File Transporter treated the symbolic link as a normal folder, and copied its contents and thus the whole iMovie library again. And again. And again ad infinitum or rather until the disk ran full.
iMovie will recreate the link if you delete it, so that’s not a workaround.