I gave Mozy’s online backup service a try. This is partially due to my effort to unburden myself as mentioned in my “Real Work” post. Two days after signing up, I was given a refund for my year of prepaid service (minus 10% “credit card processing fee”). What went wrong?
PLEASE NOTE: I am not associated with Mozy. If you contact me to ask for a telephone number or for help using their product I will mock you viciously.
First, let me give you the background. My home server is a semi-retired original Mac Mini. It’s a G4 with 1 GB of RAM, and a 40GB internal drive. Attached via USB is a RAID device I use for my shared mass storage. About 30-40GB of the data on that drive is things like digitized home movies, photos, etc. – things I really don’t want to lose if my house goes up in flames. I keep a full backup of everything important on a hard drive stored in my fireproof safe, but I have to manually connect it and mirror everything over periodically. This is becoming a bit too burdensome and I sometimes forget.
Enter my desire for online backup. I want everything to run from the server (it’s the only device I want running 24/7 because it consumes very little power and can be tied up without impacting anything I do). Because the server is a G4 machine, my options are limited; most of the Mac-compatible services require an Intel Mac. I can’t understand the reason for this, when it’s relatively simple to flip a switch in Xcode and make the app a universal binary. I can’t think of a single thing these backup services do that would prevent a universal binary to include PowerPC architecture. I digress.
Mozy looked to be the only reasonably-priced solution (in terms of storage) that I could run from my server. I immediately signed up and prepaid for a year. I installed their client and began setting up my backup sets.
The Mozy Home Client’s User Interface
The first thing I noticed was Mozy’s UI. It’s divided into two components: the MozyHome app and the status bar item (from which you can request a backup to start, open the backup status window, or launch MozyHome).
The status window’s “time left” seems to live very much in the moment. Instead of averaging its completion time estimate over a window of time, its estimate jumps around wildly as slowdowns and interruptions occur. This happens far too often to give you any real sense of how long a backup will take to complete.
The MozyHome application is where you configure your backup sets. It is, in a word, confusing. In another word, it’s minimal. Each “set” is either an inclusion or exclusion list. You choose a folder or individual file. Subfolders are included automatically. Traditional backup systems show you a file structure tree with checkboxes that allow you to define sets or subsets of data in the tree (even a partial subset if a subfolder or two are unchecked). This “tradition” makes it far easier to specify files to back up and what among that set to exclude (like that “Tennis Rackets, Midgets, & Car Batteries” porn folder you’d rather not have transmitted anywhere).
Instead, Mozy forces you to create a different backup set wherein you check a box designating it an “exclusion” list. You then add that troublesome “Tennis Rackets, Midgets, & Car Batteries” folder. Two separate “sets” for the same “Home Movies” folder? Come on. That kind of usability bullshit is for Windows. Not surprising, given Mozy added Mac support after they launched. It’s clearly an afterthought, and I’ll give you another reason why in a moment.
Mozy has a list of behavioral problems.
First and foremost in my list of complaints is Mozy’s apparent cluelessness about security. The Mozy daemon, which sits in the background watching and syncing changes with the backup service, is set up to be run as the root user, in the “wheel” group. This root/wheel configuration presumably allows it to get to any files you want to be backed up. This is just asking for trouble (I’ll not bore you with a list of possible scenarios). In my opinion it’s a demonstration of security cluelessness.
Mozy could effectively provide their core service with just a bit more installation effort. Namely, they could create a “mozy” user account on the user’s machine and prompt the user for an admin password when Mozy sees that it needs access to read a backup set when the set is created. Run the daemon under this user account (not root) and it’s a lot safer. I did this very thing. I created a user account for it and edited its /Library/LaunchDaemons plist file. I then gave it read access to my storage drive. It saw the files just fine. Unencrypted user home folders? Do the same – grant Mozy read access to those users’ folders. Works fine.
I have to assume part of the root/wheel issue is to allow access to back up system files. This in itself makes no real sense, however, given a user wouldn’t be able to restore their system from a cold start unless they first installed OS X, then Mozy, then restored system files. I just don’t think that’s a reasonable use. Mozy should focus on user data and user data does not require root access to back up. I’ll say it again: cluelessness.
Mozy’s servers are slow. I mean “christ-on-a-crutch-I’ll-be-eighty-by-the-time-this-100MB-file-is-backed-up” slow. Occasionally, I’m able to make full use of my upload speeds with Comcast (which isn’t saying much, but let’s focus on Mozy for now). Three independent speed tests during the often sub-Mbps transfer rates showed it wasn’t the ISP. Mozy’s pipes are just not up to the task, in my opinion. It gets much worse during the late evening hours. This causes timeouts and eventually complete failure of a backup attempt. That brings me to Mozy’s lack of error recovery.
Normally, when trying to upload something important, a system will just keep trying (preferably at sane intervals) until the user decides to click the cancel button. Not Mozy. No, according to its logs, after 15 failed attempts to upload a given file (which are apparently tried as quickly after the last failure as the computer can do it), Mozy gives up trying. I mean it really gives up trying. It completely stops the backup. Given an initial backup can take days (it kept saying nearly two weeks for mine), this seems like a completely artificial and unnecessary limitation.
This is the serious kind of limitation. The kind that makes it impossible for all but Grandma (with her 100 or so heavily-compressed thumbnails because she doesn’t quite know how to curate her digital photos) to make any serious backups. I personally never got past about 7% before the backup failed due to this retry limit being exceeded when their servers got busier and busier before being choked out entirely (you could see the rate falling and falling until it hit the “frantically retry then die” logic). Not a single successful backup of the stuff I needed to back up. Only small test sets with small files made it and those took for-goddamned-ever.
Several very minor changes would make Mozy far more reliable, making its slowness a mere inconvenience rather than a death sentence for your backup attempts.
First, remove the hard limit on retries. Its very existence in a backup client is idiotic. I want my files to be backed up and you’ll damn well keep trying until I tell you to stop. No excuses. It’s what I’m paying you for.
Second, stop trying so rapidly. Even if there were a higher limit, you’d eventually blow your wad during any extended outage. How about a throttled retry rate? When it fails the first time, try a second later. If it fails then, try ten seconds later. If it fails after that, try a half-minute later. Then a minute later and so on until you reach a sane ceiling of a wait limit (say 5-10 minutes). That should strike a nice balance between recovering quickly from a brief outage and not choking the connection trying to reach a server that’s going to be down for a few hours.
Third, if there’s some sort of problem, how about an unobtrusive notification? A little “warning” symbol on the status icon showing an issue was encountered would go a long way. For example, it could warn of an ongoing outage that went on longer than some threshold span of time.
Service with a Smile
After bending over backwards to redeem Mozy (because I really wanted for it to work), I decided to cancel and seek alternatives (more on what I chose in a moment). I asked for a full refund, given their service failed me completely (again, in 48 hours, it did not manage to successfully back up a single useful thing – only small tests).
A day later, I received an e-mail stating about $49 out of my $55 (prepaid for the year) had been refunded. I reminded them I asked for a full refund, given their failure. I also rather unabashedly asked them why they felt they deserved to keep any of my money after failing so completely. The response was they have a 10% credit processing fee for returns.
Now, even for a small credit card point of sale system, the fees are not 10%. This is just Mozy’s way of keeping some part of your money. Just call it what it is, Mozy: a Fuck You Fee.
Even eSellerate, who processes my business’s sales, eats the credit processing fees. When one of my customers wants a refund for whatever reason, they get 100% of their money back. I wouldn’t have it any other way. Mozy, however, apparently would.
The only alternatives left to me were a bit expensive per Gigabyte. So it seemed. I’d completely ignored Amazon S3 as it seemed to be extreme overkill. I also admit I didn’t like the idea of being charged for transfers or even listing the files in my “bucket”.
With few reasonably affordable alternatives remaining, I took a hard look at how much I’d actually transfer, how much I really needed to have off-site, and picked a “grow into” storage size. As it turns out, with heavy usage and more space than I need, it comes out to only twice Mozy’s monthly price: about US $10 per month for 60 GB of storage and 2 GB of uploads and downloads. Those up/down transfer amounts per month are strikingly higher than I believe I’d need. Add to that the fact Amazon is not charging for uploads until June, 2010, my initial backup will cost me nothing. Only the storage space I use. This made it very attractive.
How did I do it? Well, I’m still doing it. My full backup is done. As in, 16 hours and it’s done. Two weeks, Mozy? Really?
I used Panic’s Transmit (I own a copy) since it added S3 support. To save on transfer fees, however, I’ll need some rsync-like magic (the kind Mozy and other backup services offer, making it necessary to upload only the parts of the files that actually changed since the last backup). It turns out there’s an rsync-like ruby script specifically for S3 called s3sync.rb that can be run in the background as a cron job. Excellent! I haven’t set it up yet, so I can’t comment on it, but it’s promising and may meet all my needs.
I may post on the subject later, but I wanted to get this Mozy review out ASAP, as others have been asking me about my experience on Twitter or by e-mail. They were doing it because I was admittedly bitching quite loudly about the experience in realtime. I hope you find this useful, cursing and all.
Some things have happened since I wrote this.
I now use Arq and it works wonderfully. I can throttle the transfer rate, schedule backups, set an S3 service budget (older backups are “pruned” to keep your storage under your defined cost limit), etc. The only thing is, for multi-user backup, you still have to understand and assign proper user permissions (or store everything you want backed up in some openly-accessible folder or volume – not an option for a responsible business owner… or an avid porn collector). I’ve settled into a stable and predictable data growth rate (and monthly transfer rate). Even backing up more liberally, I’m only spending $10/month total and won’t tip to $11 for probably another six months or so. Remember: I’ve got home movies, photos, music, etc. and gigabytes of business data (including source code, sales records, gigantic Adobe Illustrator ad files, etc.).
On the 16th, the technician who informed me there was a 10% credit processing fee e-mailed back with the following lame excuse:
I missed the fact that it was in the first 30 day. here is the rest of your refund.
So I did eventually get a full refund and it only took three e-mails about the subject (after the initial cancelation) to do so. Ignoring that several of my messages on this trouble ticket referred to the fact I’d just signed up a few days before, and that one of my “where’s the rest of my refund” messages specifically spelled this out, I feel better knowing they didn’t get a single cent from me after this experience.
So, while I did eventually get all my money back, the effort required after such a complete failure still leaves me with an overall terrible impression of Mozy.
Mozy has since upgraded their client. They’ve likely upgraded their server infrastructure too (I can’t see how they’d have survived without doing so). I haven’t bothered checking to see if the issues I raised were addressed. Frankly, given what I saw at the time and the experience I had with their customer service department, I don’t care to give them a second look.