Problem / Outcome Summary
- This article is an opinion article that will also show you a couple of tricks that should help you speed up your CrashPlan restore.
Why might I want to read this?
- To speed up your CrashPlan restore
- To learn a little more about how CrashPlan works
To be clear, why shouldn’t I just use the standard CrashPlan restore?
To be fair, you absolutely can use the standard CrashPlan restore. However, you may find that your restore speed does not perform as fast as you expected. In my case, the CrashPlan restore window on my Mac said it was running at between 15-20Mb/s. That speed is not bad in my country, however the CrashPlan application said at this rate it would be several weeks before my data was restored. On top of that, doing a few calculations, I found my actual restore speed was 4Mb/s. This was not going to be a product I subscribed to for long if I couldn’t speed this up.
Why I chose CrashPlan as my personal backup solution
After some fairly extensive research, it’s benefits over other (as at December 2015) cloud backup solutions are quite substantial. In particular it’s price, it’s unlimited backup and it’s promise to ‘Never Delete anything’ gives you an outstanding retention time-frame that no other product currently beats. It’s application is also fantastic, (well almost – more about that below) and a really big deal to me is that it offers true private encryption so your social security numbers or IRD numbers aren’t plastered all over the web begging for identity theft. Seriously, for the price, no other product get’s close to the value of Code 42’s CrashPlan. After several months of use and a catastropic failure on my NAS filesystem (therefore a CrashPlan restore), I’ve now decided to sell my offsite NAS backup and replace it with this.
Why CrashPlan is the only product that could restore my data
As mentioned above, I recently had a catastrophic file system corruption which required me to restore my entire backup. The thing about file system corruption is that on the outside, your files still look like they’re fine. They still copy and you can still back them up. Unfortunately this means any automated backup solution will actually back up the corrupted files intact so that when you restore them, you just get a duplicate corrupted copy. Most other backup solutions do not allow you to ‘go back in time’ with your files and those that do have limitations to how far you can go. CrashPlan however allows me to do this, which is exactly what I had to do. Had it not been for CrashPlan’s ‘never delete anything’ policy, I would have lost all my files.
The CrashPlan restore speed problem
So I needed to restore my data. CrashPlan’s Mac app was slow.  I had two issues:
- Restore speed running at an actual 4Mb/s
- The client had frequent disconnections, similar to that of unplugging a network cable. The error I was getting was ‘Unable to restore because destination is unavailable’ and this error would come and go randomly, stopping the restore in the process.
Searching on google through the CrashPlan forums and generally there were rumblings that the Mac app was not great and worse that the Code42 support (customer champions) were not so great either. After much scouring of the web, I phoned and when that failed, logged an online ticket.
I waited and unfortunately the response from Code42 seemed to align with the complaints on the internet. Knowing how support centres work (I’ve run a few myself), there are SLA’s (or KPI’s) to meet. Unfortunately some call centre managers let this become a priority over quality. Here’s what happened:
- The response was fast and apologetic and I expect largely copy and pasted
- I was informed 1-3Mb/s was a typical restore speed and no suggestions were made to help resolve this
- I was informed an average data restore rate for CrashPlan is 10-30 gigs per day
- I was informed if I happened to have a fast internet connection it is unlikely to make a difference because it’s an affordable shared service
- It was implied (albeit very politely) that Code42 are only interested in helping me if my restore speed is less than 1Mb/s, to which I’d need to provide logs.
It was essentially then left to me to argue for my case. It’s worth pointing out that most customers of this service wouldn’t have enough skill to argue successfully with the customer champions which is a pet hate I have with customer service these days. That said, the service is very very cheap and the product is still very good.
So I realised there was no avenue for help from Code42 if I was getting more than 1Mb/s, disappointing.
How to speed up a CrashPlan restore and prove the customer champion was incorrect
- Change your CrashPlan client
- I switched my CrashPlan client from Mac to Linux. My new speed was 70Mb/s. The client didn’t disconnect all the time.
- Run simultaneous clients
- I was able to run both my Mac and my Linux restore clients simultaneously. This sped up the CrashPlan restore to the total of both speeds
It is clear that as eluded to on various forums and web sites, the CrashPlan Mac client performs very poorly and the customer champions aren’t working toward customer service targets, rather a ‘quick response and close rate’. It is also clear that the response surrounding the alleged ‘design’ of the Australian data centre to be around 4Mb is inaccurate. To give you an idea, on just the linux computer, I restored 53GB of data in about 60 minutes.  Compare that to the suggestion that I should only be able to restore 30GB in an entire day.
As always, we welcome your insights and opinions in the comments section below.
For a quick howto on how to set up CrashPlan on Ubuntu Linux, have a look at our HowTo article here.
Marshalleq
Thanks alot for your article. I had the same problem (around 4Mbit/s download speed) on a Windows 10 computer when needing to restore around 1,5TB.
To my surprise I was able to “solve” the problem by using the Linux client inside a virtual machine running Ubuntu on the same Windows 10 machine. Do you thing they limited the bandwith deliberately or is it just a damn bad client?
Hey Christian, thanks for stopping by! I think it’s just a badly written client, from memory (on the Mac at least) in Java. I didn’t test it in Windows like you have, but suspected as much – good to know. What speed did you end up getting in Linux roughly?
The Ubuntu VM (1 core of an i7 and 2GB RAM on Oracle VirtualBox) uses my complete bandwith for download (50MBit). Yesterday I was able to restore ~540GB.
https://uploads.disquscdn.com/images/6bb97bfbe1c9e56b71274b1e2aec69ecf76211bfb97552690450a4eb77711053.png
Wow that’s fantastic, thanks for taking the time to put the bandwidth charts in. It does make me wonder if there is a designed speed limitation in the Windows and Mac clients. I’m not wondering if it would be prudent to keep previous versions of the Linux client in case they decide to ‘fix’ this.
How did you share between the linux and mac systems? Also- you mentioned you were combining speeds between the linux and mac systems… How did you do that? They can’t both be one? Could you please explain the process?
Hi Lior, I think you’re asking around the same thing with both questions, but come back and let me know if I didn’t cover it.
In my case, when I said I was combining speed, I simply selected separate files or folders to restore on each machine. This worked in my case because I knew the maximum transfer speed of even the Linux client, was much less than the maximum transfer speed of my internet connection.
So, by setting up one download session on Linux for one set of files and one download session on Mac for another set of files, this increased the total throughput. Then when finished, I simply copied the restored files back to the same location, which in my case is a NAS. Does that answer your quetsion?
Thanks,
Thanks for replying. It makes some sense, but I still have a couple of questions- Do you run your Linux on a virtual machine AT THE SAME TIME with the Mac machine? Or are they on 2 machines? Also, what protocol do you use to transfer between machines?
Hi, in my case I did this on separate machines, but while I didn’t try it myself,
@disqus_fK49zTpJ70:disqus above, definitely used a virtual machine. The limitation is not the computer, rather a combination of the Operating System and the client. So yes, you can run a Linux virtual machine at the same time as on your Mac or Windows host. Christian didn’t need to as his Linux machine was already running at the full speed of his available internet bandwidth.
As far as protocol goes, I probably transferred the files to my NAS with rsync. However, it would be equally acceptable to use SMB, AFS or NFS. It depends on what works for you. In your case, being a mac / windows system, I’d recommend learning a little about rsync as it’s an amazing tool. A typical command to get you started would look similar to: rsync -avh –progress –partial /localfile ipaddress:/remotefile it would then prompt you for username / password. Give it a try! (And report back if you need more help).
Glad I found this article. I was trying to recover over 500 GB on my Mac and it was taking forever. After a week of waiting for the restore, we went away on vacation. I left the computer on for a week. It did not finish, in fact it stalled. So I came back from vacation and was sorely disappointed. Your solution worked like a charm. I installed Ubuntu in VirtualBox on my Mac. I installed CP on Ubuntu. Then I shared a folder on my Mac through VB. Then I ran a restore to the shared folder. It only took about 15 hours! Average speed on my Mac client was 65 Mbits. Thanks!
Awesome, it makes it so much more worthwhile when a comment is left here on how it works for you, thanks so much for letting me know, 65Mb is pretty good speed too!
I’ve found a semi-permanent solution in that it will reliably uncap my restore/download speed of 3Mbps, but sadly the issue reoccurs after a system reboot. This solution is really quite simple;
Double click on the CrashPlan icon to open the command prompt.
Type “deauthorize” to sign out of CrashPlan and close the prompt.
Manually sign back into CrashPlan and allow the synchronization process to complete.
Start a new restore process.
(Please note that typing “reauthorize” in the command prompt does not work, you must log back in manually)
Disclaimer: I’m running CrashPlan Home on Win 10 and only claim to be able to uncap MY restore/download speeds using this method, I sincerely hope it works for everyone, however I DO NOT claim that it will work for anyone else other than myself. Good luck.
Thanks for the tip! That’s quite unexpected, but extremely useful to know. I wonder whether that makes a difference in linux for even more speed…. ;). Probably not.
I first noticed it when I decided to use a laptop to run a 2nd restore process. To do this I needed to install CrashPlan and naturally sign in. It worked great in this setup, until Windows auto updated and rebooted. The download speed was then capped. Through a bit of online digging, I decided to deauthorize and log back in. The uncapped download speed came back. I then tried it on the main server with the same effect.
I wonder if the reason that setting up CrashPlan on Ubuntu works is because of the fresh login (just like my experience) or that it’s more stable… Or both.
Either way, if it works…. It works 🙂 And if it’s even faster on Linux on top of that, more power to you 😀
I think Ubuntu worked over and over, I didn’t have to do anything special. So what we might be seeing here is the Windows client has an unpublished speed limitation that is removed by deauthorising crashplan? Anyway, what speed did you get?! 😀
That’s great, the Ubuntu option certainly sounds robust.
I don’t feel it’s my place to decide what the intended operation of the software is. But please allow me to put forward that rather than saying that CrashPlan are enforcing an unpublished speed limitation, it could just as easily be said that the auto sign in procedure on reboot (presumably the “reauthorize” command) doesn’t adequately sign the computer back in, and the the server’s fall back to a capped speed or a protocol that is limited in speed. Signing in from scratch may actually force the intended operation.
One implies that CrashPlan are acting covertly, where the other is simply an honest coding error, and either or both could be correct. I guess only the dev team really knows, and I just hope it’s an honest error rather than a sneaky trick. 🙂
Either way, I’m not sure specific speeds really matter after being uncapped from 3Mbps, it’s then about what connection you have and not related to CrashPlan. My downstream is pretty mediocre compared to some of the envious speeds stated here, but the point is that what I am getting, is my full downstream.