Carbonite, Revisited

Submitted by Miles Baska on Fri, 12/07/2007 - 9:19pm.

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.

Permalink
Read more about:

Your post re Carbonite

Submitted by David Friend (not verified) on Sat, 12/08/2007 - 8:00am.

Miles:

Release 3.5, which everyone will be upgraded to automatically on Jan 15th, does support versioning, so you'll be able to go back and pull up old versions. Actually, we've been saving all those old versions for quite a long time waiting for the new user interface to be finished so the user could access them. I think you'll like the implementation -- it's very intuitive. This release also provides scheduling so that you can decide exactly when backups do or don't happen, if you feel the need. This is useful in an office environment where there are a number of PCs sharing one internet connection and you don't want any backups to be going on during business hours, for instance.

I'm not sure why you think it's a good idea to back up everything at once, though. Once you start a Mozy backup, it's going to slow down your PC. You can adjust how much it slows it down, but it's still noticable degradation and annoying. And you don't have any choice. Carbonite gets the work done during the moments when you're not using your PC for something else. Almost everyone who has evaluated this method finds it a big step forward from the old-fashioned batch jobs. Mozy tries to do "real time" backup by starting a batch job every 2 hours, but it still gets in your way because it is not context sensitive. You're much more likely to be backed up to the minute with Carbonite because it is working at all times.

As for your customer's system, I'm afraid I don't understand what you are getting at. I can't envision a situation where Mozy would work and Carbonite wouldn't. You'll have to explain it to me in more detail. You can email if you'd like at .

As for the encryption, we start with a proprietary 1024 bit key and use that key to seed 448 bit blowfish keys that are uniquely generated for each backed up file. It's an extra layer of protection and I don't think anyone else does this.

It sounds like our customer support might not have made the license transfer happen correctly. If you'll give me the registration emails, I'll find out if it was on our end or yours. BTW, the 9-5 customer support refers to our live telephone 800 support, not email support which is available any time. Mozy, I should point out, does not offer phone support at all for its Home product.

One more thing, Miles, you should also consider what happens when you try to restore an entire PC. I don't like pointing out the flaws in competitors' products, but this is a significant issue. From other blog posts I have seen and my own experiments, Mozy has a serious restore problem. This post, on DownloadSquad, explains the problem, and I expect it is inherent in the proprietary way Mozy stores their data:

"No problem, he logged into Mozy, his online backup service to access his 60GB of offsite data. But he had to wait 12 hours before the data was ready, and then he had to download 100 different dmg files. He wasn't pleased.

This is a post by Mozy's own COO:

The Mozy restore process has needed improvement in the past, but we have made changes in the code and are seeing a positive impact. We have also started shipping external drives to those who need to restore large amounts of data in the event of a disaster. Our support team is here 24x7 to help anyone with their backup or restore. EMC is committed to investing in the MozyHome consumer service, so you will see even more updates and enhancements. - Vance, Mozy COO,

If you have to resort to sending out an external hard drive to someone who needs to recover their data, something is very wrong with your restore process. Carbonite starts restoring immediately and can restore 20GB in less than a day, even over a residential DSL. Why on earth would you want to pay extra and wait for an external hard drive to be mailed to you?

Dave Friend, CEO
Carbonite, Inc.
Carbonite Online Backup

RE: Your post re Carbonite

Submitted by Miles Baska on Sat, 12/08/2007 - 2:59pm.

First, let me say thank you for your time and thoughts -- having you join me in this public discussion tells me something about your commitment to your product.

For public consumption, let me say that David sent an email to me, asking for my customer's account information, and that he would personally see that the situation is resolved.

RE: the 3.5 release -- sound like the new version cures two of my stated concerns (versioning and scheduling). I look forward to the upgrade, and that it's going to roll out automatically to all Carbonite users.

RE: encryption. Blowfish, a method created by famed cryptographer Bruce Schneier in '93 as a drop-in replacement for AES, has never been broken. It's open source and therefore available for public review and analysis. It's computationally very quick, and functions very well on even dated hardware. IMHO it's not advantageous to mess with it -- adding additional encryption layers only degrades performance.

Now, the backup philosophy: batch vs. real time. Let's say there are three files -- one is a detail file (D), used by all workstations and always active, and the other two files are only used occasionally -- let's call them Master1 (M1) and Master2 (M2). M1 and M2 are only active when detail relevant to their summary roles updates D. Now, let's presume there is no roll-back function -- but that M1 and M2 can be rebuilt, if needed. For the sake of this example let's assume Window's shadow copy is available.

Mozy's method prepares a snapshot of all file changes very quickly, all at once. That snapshot is encrypted and stored, using Blowfish, and communicated to the Mozy servers with SSL (same comm as Carbonite).

Carbonite's method takes individual files, in a catch-as-catch can manner. Carbonite detects a change to D and M1, and begins processing D with your own encryption scheme. While working on that, a process takes disk or processor resources, suspending Carbonite. The active process has changed D and M2. When it terminates, what will Carbonite do? It has an internal versioning problem -- it's cached D is no longer correct, but M1 is fine, and M2 now needs to be backed up as well. If Carbonite updates the only version you store on your server, the backup set will be invalid. And worse, restoring the backup will result in an error -- D is no longer "in balance" with M1 and M2, forcing a rebuild, which in turn will remove all traces of just what activity caused the out-of-balance condition.

Perhaps this example clarifies why I prefer to schedule a backup process -- and why versioning is so important.

I have Mozy set to become active only when there has been no keyboard activity for 3 minutes and my processor activity is less than 70%. I have complete choice over how this backup should occur (no idea where your two hour comment comes from) -- and I can even kick it off manually, if I so desire. I get a summary when I boot and the same summary when Mozy completes, but I don't otherwise see any degradation in my system. True, their phone support isn't available to users of the free product -- only for users of the commercial product -- but we are talking about business here, and that comment isn't relevant.

Now, about a system restore. Neither Carbonite nor Mozy are going to do complete, bare-metal restores. Both are only getting user data. I've done complete restores with Mozy, but not with Carbonite. I've also used Mozy to get a specific file that I'd deleted a week ago and found I needed -- the joys of versioning, again. I can tell you my own experiences don't match what you say -- I've gotten complete datasets, in a single archive. True, my archived files didn't exceed 2G -- a limitation placed on Windows files -- but they were standard .zip archives, not .dmg files, and compressed -- it has never taken me more than an hour to get my complete dataset back from Mozy. I suspect the user in question here had some 'issues', peculiar to their own situation. They may need to RTFM and select a different restoration method.

The enhancements hinted at by Mozy's COO took place last week -- the service is now a LOT more responsive. I think the comment re: an external hard drive is in response to a rebuild -- Mozy can make your complete dataset available as a download, or they can put it on DVD and send it to you. In the case of a HUGE amount of data, they are shipping you your restore datasets on an external drive.

I've tested both Mozy and

Submitted by Andrew Forrest (not verified) on Sat, 12/08/2007 - 2:56pm.

I've tested both Mozy and Carbonite and I think you (and EMC for that matter) got it spot on the first time. I recommend Mozy to all of my clients because of the file versioning, continuous backup and overall higher quality of the service. I recently decided to give Carbonite another try and was again left with a less than impressive experience.

Technology wise, Carbonite has always been a step or two behind Mozy and I keep hearing over and over about how "the service will get better soon" and "add this and that feature". I would guess that Carbonite's investors are experiencing buyers remorse and sadly Mr. Friend has resorted to bad mouthing the competition and begging for business partnerships via awkward video clips.

If you are listening Mr Friend - Data restores via hard drive are yet another advantage Mozy offers over Carbonite and again you have missed the boat. Have you ever tried to restore a 100 GB exchange server over a DSL connection with a panicked client breathing down your neck? And what the heck IS 1024 bit Blowfish? Please enlighten us.

RE: I've tested...

Submitted by Miles Baska on Sat, 12/08/2007 - 3:21pm.

Perhaps you missed David's explanation of their encryption scheme -- they are using some combo of Blowfish and AES which, IMHO, is unnecessary and computationally WOFTAM. Further, David states the keys are always being regenerated -- which puts the data at risk. Let me create my own key, let me keep my own key secure, and don't mess with an open-source encryption method that's proven and trustworthy.

I think David felt the external drive was for backup purposes -- to adequately supplement a flawed online backup. That's not the case -- Mozy offers your dataset, shipped to you, on DVD or an external hard drive, when you need to restore your data. And yes, this costs money above and beyond a simple download solution -- which, as I stated earlier, has never taken me more than an hour to perform (with a 5M cable, a 6M DSL, and a 7M cable connection) -- and I've done a few of them.

Mozy was recently purchased by EMC, a company with a global presence. Carbonite, Inc. didn't come up on my Hoovers search. EMC is a $11 billion company. I haven't seen the CEO of Mozy or EMC take the time to join us here. So, sometimes, smaller is better.