Skip to main content

CrashPlan limitations

After a few weeks using CrashPlan PRO for small business (not the free tier!) I tried contacting support to ask how to do some underexplained things, and/or to open some bug reports/feature requests. Like:
  • How to know which were the last backed-up files? or, when was a file last backed up? (maybe some useless-but-frequently-updated file is slowing down backups of bigger and more important files?)
  • The app defines backup sets, but they don't seem to correspond to "restore sets". How to restore a particular set?
Support's answers were pretty underwhelming, bordering on canned-responses; but I found that Code42, the makers of CrashPlan, have an API to access the backup data. So I browsed a bit to see whether it'd be easy to do myself what I wanted.

It just can't


Interestingly, the API explains rather well the lack of features I was asking Support for. Chicken/egg problem?
  • You can't easily answer the question of "what files got backed up in the last snapshot"?
Looking at the API, there doesn't seem to be a concept of snapshots happening at a point in time. Looks like each file has a period of time in which it exists; and you can check what files exist at a given moment in time; but there is no concept of snapshot containing the files backed up at some run of the program.

I guess I was expecting such a thing because of the CrashPlan application behavior itself (it starts a "batch" every 15 mins by default); also, this is how Time Machine organizes its backups.

  • You can organize your files in backup sets, each of them with different parameters: frequency, priority, etc. But there is no concept of restore sets: when restoring, it all is a directory tree, shown at a given date.
This matters because if you plan to use your backup for anything more subtle than restoring big swathes of your files, you'll have to do it blindly. The app gives you a calculation of the size of the transfer when you select what to restore, but is rather inadequate if you want to (say) restore a expectedly small folder that at restore time turns out to be huge: you can only go deeper into the tree and deselect subfolders until you blindly find something that makes the calculation go small enough.

But wait, actually the API neither seems to have a concept for backup sets! Which means that the backup sets offered by the application are probably implemented client-side; which partially explains the lack of corresponding restore sets (though, couldn't they also fake it client-side?).

And it still gets worse: it also explains horrible kludges like the fact that if one backup set has some quirk (like a filename exclusion pattern) and another doesn't but gets sent to the same destination, then BOTH get the same exclusion pattern implemented on the server. Meaning that the exclusion pattern in one backup set causes the SERVER to DELETE files in the second backup set. Doesn't this smell like data loss waiting to happen? How does a backup service even allow the possibility?

Furthermore, given that the exclusion pattern seems to be implemented/reinforced in the server, this means that you already lost the bandwidth and time sending the backup (which actually might make you feel complacent because things are being backed up!). Just for them to be trashed in the server afterwards.

Another not-good surprise is a functionality to "verify selection". Turns out that, even though CrashPlan's client seems to follow changes to the filesystem in realtime, from time to time it needs to re-check the file selections. One can select how frequently to do this check; the default granularity is 1 day, and it takes hours to finish, during which I'm not sure the backup is working. In all, this seems to mean that if you have a new directory, it can take longer than a day to be noticed and backed up.

So, back to customer service. They barely answer questions; the answer seems to always be "I understand that you want to . CrashPlan allows you to do . Regarding : that's a great idea! Please post it in our feedback forum."

Posting in the feedback forum sounds reasonable, until you realize it's a pretty much deserted StackOverflow-looking place where a dozen feedback items gather dust. Maybe that's because CrashPlan takes days to approve new posts; it took them about one week to approve a couple of mine. And it certainly doesn't look like the delay is because of any high traffic.

Similarly, I had a problem downloading an invoice. I opened a ticket; it took them one day to answer that they're having problems with the server (exactly what the initial error message already said, duh) and some billing agent would contact me shortly. It took them longer than a week to finally send me the PDF - and the underlying issue was unfixed, so I had to repeat the dance next month. UPDATE 2018: For the last couple of months, the invoices are coming in the mail. Yay :P.

The competition


So what about the competition? The evident alternative is Backblaze. But actually I already tried them before trying CrashPlan, because I loved their reports on hard drive reliability. Alas, Backblaze only restores as big ZIP files. That risks making a proper restore complicated at the logistics level at the very least, and that's assuming that the macOS metadata lost in the way is unimportant. Whereas CrashPlan allows you to just restore whatever you want in place and you can expect things to actually work as-is.

Also, Backblaze deletes older-than-30-days data. I am not sure that is good enough against ransomware; in contrast, CrashPlan by default never deletes old data. Oh, and it backups network drives.

Furthermore, in my very slight contact with Backblaze's support it looked as canned-response as CrashPlan's. When my trial period was ending, I got a mail asking whether there was some feedback for them about why I would not get into the paid service. So I answered, hoping to help. This answer got turned into a support ticket (uh, OK I guess). The ticket got seemingly "automatically archived" a few days later, of which I was dutifully informed (huh? so why did you ask for that feedback?). A few days even later, I got a questionnarie about how well my ticket had been dealt with! (WTF just go away already! Way to waste a prospective customer's goodwill...)

At the end of the day the most interesting thing is probably that both Backblaze and CrashPlan do stay in business, so they must have a happy-enough set of customers. Am I the only caring for these details? Certainly I wouldn't have found these problems / bugs / feature requests if I hadn't tried doing some restores, which few people seem to actually try until disaster strikes (meaning, too late).
... speaking of which, I still didn't try making a full restore from Time Machine. Hmmmm...

As for my case, I will keep CrashPlan, but just as a coarse piece of a redundant backup plan. Originally I thought I would be able to get rid of my TimeMachine server, but now I don't think that's the best idea.

Non-issues


I started my cloud backup adventure by checking whether CrashPlan and Backblaze had any European servers, for better speeds and hoping for better data protection. They don't have any. Looks like a couple of companies in Europe try to take advantage of this vacuum to implement their own cloud backups piggybacking on CrashPlan's name and PROe software, but they looked too shady/oportunistic to me. One (or two?) didn't even answer when I asked about concrete prices.

So I ended up trying the normal, non-European servers of both Backblaze and CrashPlan, bracing myself for longer-than-month uploads (given some comments I had read). But Backblaze saturated my 10MBps upload, and IIRC a full backup of about 1M files / 100 GB would have taken less than 1 week. CrashPlan rarely saturated the upload, but still needed only about 1 week. So speed was rather not an issue for me. (In case it matters, I'm in Warsaw, Poland).

And regarding data protection, both services offer client-side encryption, so data is theoretically safe. Of course there's no way to know for sure without having an open source client to check what happens with your private key, but oh well...

The future


Ransomware is on the rise, and cloud backups are advertised as a solution. So I wonder how long will it take until some new ransomware starts its work by disabling backups.

CrashPlan stores deleted files without time limit, which should be better than Backblaze's 30 day storage. Still, CrashPlan immediately deletes backups of a directory if you deselect it in the client. Sounds like a brilliant way to shoot oneself in the foot.

CrashPlan has an option to lock with password access to the client application. I wonder whether that's enough; I asked support whether preferences could be tampered with and still have them picked up by the application, and they mostly ignored the question. Time will tell.

Comments

  1. Another problem with CrashPlan: even though it has a promising feature to stop backups while on battery power, it is full of cop outs. Turns out that CrashPlan has a number of states, and while it might not technically be *backing up*, it might still be synchronizing data with the servers or "maintaining backup files" or whatever while on battery power, and using up to 40% of CPU - with all the performance and battery life problems that implies. I *think* I have seen CrashPlan still working like that even while offline!

    I contacted Customer Service, and they just advised to give CrashPlan access to more memory. Hello 90's! And still that is only to *hope* that the synchronization or whatever finishes quickly. Not good, not good at all.

    ReplyDelete
  2. Also related with the different states in which CrashPlan can be: in some of those states, you just can't restore files! You are recommended to use a friend's computer, or at the very least play with the computer backup ID during the restore and then readopt the "old" backup! [1]

    This is crazy, and makes me gain new appreciation for how transparent Apple has managed to make TimeMachine.

    https://support.code42.com/CrashPlan/4/Troubleshooting/I_need_to_restore_a_file_but_CrashPlan_is_synchronizing

    ReplyDelete

Post a Comment