Carbonite, Revisited

The best-laid schemes o' mice an 'men

Gang aft agley,

An'lea'e us nought but grief an' pain,

For promis'd joy!

To A Mouse, On Turning Her Up In Her Nest With The Plough

    Robert Burns, 1785

Last October I mentioned Carbonite and said I preferred Mozy. David Friend, Carbonite's CEO, stepped in and corrected me on a couple of points, and I promised I'd take another look. I recently had a chance to do just that. The customer who got me involved with Carbonite in the first place has built a new office, and that meant a new computer network. I set him up with a new server and new workstations. I switched his primary app from a standalone box, dropping Carbonite, and installed Carbonite as trialware on his new server. I spoke to their customer support before starting on this adventure, so I had a game-plan with their blessings. The software installed easily, and in just a few minutes I had it up and running and tied to my customer's account. Everything looked pretty good -- the user interface was simple enough, with color-coding to tell you what files were backed up and what files were not. But I began having some second thoughts, even though I'd been blessed. Turns out Carbonite does not do versioning (it's planned in a new release). They are only storing the most recent version of a backed up file. Not good, but I worked around that by keeping my own versioned backup sets locally, and letting Carbonite back up that data as well as the live data. That got me to thinking about their scheme more generally... Carbonite backs up files (from their FAQ) "at full speed when you're away from your computer and automatically slows down when you're actively using your computer so that it won't interfere with your CPU or Internet speed". Consider my customer's situation: his application allows up to four simultaneous users, and logs inactive workstations out. There are a LOT of files, and their rates of activity are widely varied. It seems to me that, using Carbonite's approach, it would be possible for some files to not get backed up for days, assuming the server is shut down at the end of the business day. If there is a failure during the day, the Carbonite backup set may have files that are no longer synchronized. In other words, the only backup sets on Carbonite that I trust are the ones created by my own versioning system. Am I waisting time trying to back up live data? To make matters worse, it now looks like Carbonite didn't transfer my customer's license to the new server, and that all datasets have been deleted due to inactivity (the trialware expired two weeks ago). I'm glad I built the server with a healthy RAID. Mozy is a bit more complex to set up, but it does versioning every time it backs up -- I can go back to any backup set created in the last thirty days. Mozy backs up all of the files at once -- it doesn't take them one at a time, based on inactivity, but on a schedule that I control. Carbonite Customer Support is available weekdays between 9am and 5pm EST. Mozy Customer Support is available 24/7 -- even Christmas. In your post dated 10/17, David, you said you were using 1024-bit Blowfish. Your FAQ says you use "a combination of Blowfish and AES". Blowfish has a max key length of 448 bits. AES has a 256-bit key length. Has Carbonite developed their own encryption methods? I still prefer Mozy over Carbonite. David, please, if you see this, post a reply.

Editors' Picks
Join the discussion
Be the first to comment on this article. Our Commenting Policies