Note: This article is part of a series. See the Index for more information.
Self-promotion: I’ve recorded this series as a screencast for Pluralsight:
If you have a Pluralsight subscription, please consider watching it. Thanks!
Updates: It is no longer necessary to replace the Java Runtime Engine since the newer installer doesn’t seem to include it anymore, so skip removing /usr/local/crashplan/jre, which doesn’t even exist, and don’t create the symbolic link.
There is a newer version of the standard widget toolkit (SWT) in the current installer, so after installing it, take a look in your /usr/lib/java folder to see what version you have. My most recent version was swt-gtk-3.8.2.jar, rather than the …3.8.0 from the original installation. Adjust the copy command accordingly.
Initially my service wouldn’t start, but after a reboot it worked just fine. If you run into trouble, reboot and try again.
IMPORTANT UPDATE 2016/10/02:
I’ve gotten a number of comments about CrashPlan not working lately. It looks like some recent update has possibly broken CrashPlan on the Raspberry Pi to an extent we’ve not seen before.
Code42 wrote a great backup program, but the Pi isn’t an officially supported platform, and never has been, so you can understand why they don’t really have any incentive to come rushing to our rescue. They never meant CrashPlan to run on ARM devices, and that’s what the Raspberry Pi is.
Some users have reported being able to get the engine running, but not the UI, and others have said that even the engine isn’t working anymore. My own CrashPi stopped working as well, and I haven’t had a chance to see if I can find a way around it. Until further notice, I can’t really recommend running CrashPlan on the Raspberry Pi. I’m open to suggestions if anyone knows a way to get it running and keep it that way, but I haven’t found one myself yet. I am looking into it, though.
If you tried recently to install CrashPlan and it failed, or wouldn’t stay running for very long, it looks like the most recent installer has fixed whatever was broken. The current download from Code42’s site should be version 4.7 or newer, and readers are reporting that all is well again.
If, like me, a previous auto-update broke your existing installation, then I suggest uninstalling CrashPlan like this (From memory, forgive me if I get something wrong)
cd /mnt/data/public/downloads/crashplan-install sudo ./uninstall -i /usr/local/crashplan
Then download and install the latest version from Code42. You’ll need to repeat all of the steps in this article, but as long as you point the backups to the same directory you were using before, CrashPlan should pick them up and continue using them, so you don’t have to start completely over. You will need to reinstall and re-patch the UI, and then sign in to your account again, just like the first time around.
Recently, Code42 (CrashPlan’s developer) updated their installation files, and the instructions in this article stopped working. Thanks to the work of several readers (see the comments), I’ve been able to revisit this article and update the instructions so that they work once again.
See the end of this article for additional troubleshooting information if you find that your installation mysteriously stops working one day.
One of the main jobs of a proper “home server” is to back up the other computers on the network. You could accomplish this through the file shares I covered earlier in the series, but I’d like to try something a little more ambitious.
There’s a great product out there called “CrashPlan” (www.code42.com/crashplan). The company has subscription offerings that will store your backups in their “cloud”, similar to other products like Carbonite (www.carbonite.com), but if you can supply your own storage, CrashPlan is free.
The free version of CrashPlan can back up to a local drive on the same computer, or to another computer that is also running CrashPlan. Your Raspberry Pi Home Server can be that “other computer”, and handle the backups for all of the computers in your house.
Note: It is possible to get CrashPlan to backup to a share on your local network, too, but it involves jumping through some symbolically-linked hoops, and won’t be covered here.
I didn’t figure all this stuff out on my own, not by a long shot. I am standing on the shoulders of other geeks here. In 2012, Jon Rogers wrote a blog post about getting CrashPlan running on the Raspberry Pi. That article is largely the basis for this one.
In February of 2013, Bion Ren posted an updated version of Jon’s instructions, replacing OpenJDK with Oracle’s Java 8 preview. He also called attention to a post by Torbjörn that solves a major configuration issue, and a comment by Brad Peterson that addresses a rather serious stability issue with regards to swap file use.
I am posting this because I wanted to gather together a complete, updated set of end-to-end instructions for adding CrashPlan to the Raspberry Pi Home Server I’ve been describing in this series. As I have pointed out before, I am by no means a Linux expert. I could not have done this without the work of those that went before me.
Before you start
CrashPlan was not written with tiny computers like the Raspberry Pi in mind. It expects to be running on a computer with more resources in general, and more memory in particular. When it doesn’t have enough memory, it will start paging to the swap file. Whether or not this will wear out your SD card is a rather contentious subject, and I’m not going to pretend that I know the answer to that one. One thing is for sure, though, SD card-based swap files are slow.
As a result, I cannot recommend running CrashPlan on a Raspberry Pi unless you have moved your swap file (and I recommend your root filesystem as well) onto a proper hard drive as covered in my “Adding a hard drive” post. If you skipped that article, this isn’t going to work for you. The SD card just doesn’t have enough space to hold backups. In order to serve as a useful CrashPlan backup destination, you’re going to have to have a big hard drive anyway, so you may as well take full advantage of it.
In addition, CrashPlan does some pretty heavy lifting in the background, compressing and pruning backups, and doing general housekeeping. This can use a lot of CPU, and make the rest of your server’s functions slow to respond. As I’m writing this, my own CrashPlan instance is using up about 60% of my CPU time compressing backups from my primary computer. CrashPlan is usually pretty good at getting out of the way when other programs need to think, at least on the desktop.
CrashPlan runs on Java, which means it can run on anything with a Java runtime. Current Raspbian images (2015-01-31 at the time of this update) already include the Java Runtime, version 8. You can check this by typing the following at the command line:
If it says “1.8.0” or above, you’re all set to go. If not, you may need to install the Java Runtime Engine (JRE) yourself. Unfortunately, I can’t find a simple JRE installer for the raspberry pi at this time, so you’ll just have to install the whole Java Development Kit (JDK). Only do this if you don’t already have JRE8, as checked in the last step.
sudo apt-get install oracle-java8-jdk
There is an additional piece you’ll need in order for CrashPlan to work. According to a user called Torbjörn on the CrashPlan forums, you’ll also need the Java Native Access (JNA) library. Install them both at once like this:
sudo apt-get install libjna-java
When the Java installation completes, you are ready to install CrashPlan itself.
Get the CrashPlan installer
Since there are new versions being released all the time, I can’t give you a simple url to “wget”. Go to http://www.code42.com/crashplan/thankyou/?os=linux, from a browser on the Pi itself, and the download should start automatically. I used the new “Web” browser that’s part of the Raspbian image, so the file ended up in /home/pi/Downloads. Depending on your browser, your downloads may go somewhere else. If you can’t figure out where they are going, just download the package from your primary computer, and copy it over on a flash drive.
When the download is complete, find the .tgz file and extract it. Since I was already in the desktop environment to run the browser, I took advantage of the modern amenities, right-clicked the file and picked “Extract here” from the context menu. Sometimes it’s nice to live in the future, if only for a moment.
If you want to do it from the command line, go to the folder where your .tgz file is:
…and type the following:
tar zxvf FILENAME.tgz
Navigate to the folder where you just extracted the installer (Note: your folder may be different):
Execute the installer from the command line.
The install script will prompt you for anything it needs, including accepting a really long EULA that you probably won’t really read (q exits the reader). You can accept most of the defaults and let the installer create any missing folders, but one directory you should probably change is the backup location.
Unless you are backing up something very very small, like another Raspberry Pi, the root partition is not going to be big enough to hold the files. Change the backup location to somewhere on the data partition. I set mine to “/mnt/data/CrashPlan”, and let the installer create the folder. You’ll get a summary and a confirmation prompt like this:
Double check all of your values, and then let the installer go. It’s a surprisingly fast installation. If there were no problems, you should see a confirmation like this:
At this point, you have CrashPlan installed, but it’s not very happy. Although the installer says the engine is installed and running, it’s actually not. You can check on the status of the CrashPlan service like this:
service crashplan status
The answer will probably say “CrashPlan Engine is stopped.”, and even if you try to start is manually, checking its status will still say “stopped”.
The trouble is that the installer downloaded it’s own private copy of the Java Runtime Engine, version 7 (JRE7). Normally, this would just be an irritating waste of storage space, having multiple copies of the JRE around, but the one CrashPlan installed isn’t even the right architecture. The CrashPlan installer has installed a JRE that assumes it’s on a desktop processor, specifically something i586-ish (Pentium, Core, etc.)
Don’t worry about it if you don’t know what that means. All it means to us is that we’re going to have to trick CrashPlan into running on the JRE that’s already on the Pi, instead of the one it installed itself. Thanks to Rainer Boehme and Matt for showing me this in the comments.
The first order of business is to blow away the useless x86 version of JRE7.
sudo rm -r /usr/local/crashplan/jre
Next, we’ll create a “symbolic link”, which is a kind of shortcut on your hard drive. Symbolic links make things in one place appear to be somewhere else, or even in multiple places. You can use them to keep one physical copy of a file, but have it appear in many different places. Here, we’re going to use one to make the raspberry pi-friendly JRE8 appear where CrashPlan put its raspberry-unfriendly JRE7.
sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt /usr/local/crashplan/jre
Patch CrashPlan to work on the Pi
CrashPlan is now installed, but it’s not very happy. If you were to look in the /usr/local/crashplan/log/engine_error.log file right now, you’d see a complaint about the /usr/local/crashplan/libjtux.so file being the wrong version. Luckily for us, Jon Rogers already fixed that problem.
Return to the terminal, and go to the /usr/local/crashplan folder where you will find the file in question.
cd /usr/local/crashplan sudo rm libjtux.so sudo wget http://www.jonrogers.co.uk/wp-content/uploads/2012/05/libjtux.so
sudo rm libmd5.so sudo wget http://www.jonrogers.co.uk/wp-content/uploads/2012/05/libmd5.so -O ./libmd5.so
These two files should allow the CrashPlan engine to start up.
Next, edit the CrashPlanEngine file.
sudo nano /usr/local/crashplan/bin/CrashPlanEngine
Find (ctrl-w) the line that starts with “FULL_CP=”, and add “/usr/share/java/jna.jar:” (don’t forget the colon) to the beginning of the string value so that the result looks like this:
Exit nano, saving the file (ctrl-x,y,enter)
To check whether everything is working, try launching CrashPlan manually.
sudo service crashplan start sudo service crashplan status
If everything went well, you should get a message indicating that the CrashPlan service is running.
Configure CrashPlan to auto-start
Having a backup system like CrashPlan won’t do you much good if it doesn’t start back up again after your power goes out. Type the following command to automatically configure CrashPlan to auto-start after a reboot.
sudo update-rc.d crashplan defaults
To make sure that it worked, reboot the Raspberry Pi, log back in, and check the status of the service. It should be running.
sudo reboot … sudo service crashplan status
Patch the CrashPlan UI
At this point, you have a working CrashPlan server, but no way to communicate with it. You need to get a GUI talking to the CrashPlan engine so that you can configure backups, change preferences, and generally fiddle with the knobs.
LiquidState has a very detailed walkthrough of configuring CrashPlan to answer to a UI running on a different computer. If that’s how you want to do things, then go ahead, but it’s not that much harder to get the UI running on the Pi’s own X desktop.
If you were to try the CrashPlan icon that the installer has placed on your X desktop right now, it wouldn’t work because the version of the Standard Widget Toolkit (SWT) library that CrashPlan installed won’t work on the Raspberry Pi. You can double-click that icon all day and it will never get you anywhere until we fix this problem.
Install a compatible version of the SWT library like this:
sudo apt-get install libswt-gtk-4-java libswt-cairo-gtk-4-jni
Next, replace the SWT library that CrashPlan installed with the compatible one. You’ll notice that we’re totally lying about the filename. CrashPlan isn’t meant to run on ARM processors, and in 4.8 they started choosing between x86 and x64 versions of the libraries dynamically at runtime. We’re renaming the ARM-compatible version of the toolkit so that it appears to be the x86 file that CrashPlan will end up trying to run on the Pi.
sudo cp /usr/lib/java/swt-gtk-4.3.2.jar /usr/local/crashplan/lib/org.eclipse.swt.gtk.linux.x86.jar
Note: Thanks to Jeremy Nauta for identifying newer versions of these libraries being used by CrashPlan 4.8
The exact version of this file is subject to change, so if the command complains, use tab-completion to help find the correct filename. Type up to “/usr/lib/java/swt” and then hit the Tab key to fill in the rest. This file has changed more than once since this article was first published.
You can now run the CrashPlan UI directly from the shortcut the installer put on your X desktop. The first run can be pretty slow, so give it some time.
You’ll either need to connect to an existing CrashPlan account, or create a new one. It’s been so long since I signed up, that I honestly couldn’t walk you through the steps anymore, but all you’re going to need is what’s included in the free version.
Back up your stuff
Now that you have a CrashPlan server, it’s time to start backing things up. Install the CrashPlan software on the computer you want to back up, and open the UI. Sign in using the same account information you used above.
From here on, it’s just business as usual. Choose what you want to back up, and select “another computer” for the destination. If you signed in with the same account on the client and server, they should see each other in the list, and you can pick the Raspberry Pi as your backup location.
If your computers have trouble seeing each other, I’d suggest looking in the support section of the CrashPlan site. CrashPlan does a pretty good job of opening its own firewall holes via UPnP, but perhaps your router doesn’t support that, or maybe you’ve turned it off on purpose. Such networking issues are beyond the scope of this article. Your mileage may vary. Google is your friend.
Warning: The first time you back up another computer it will take a very long time, and it’s going to peg the Raspberry Pi’s CPU, just like when MiniDLNA was indexing your media. Don’t worry, you’re not going to hurt the Pi. Mine was at 100% CPU usage for more than a day, and the CPU temperature never rose above 64°C. As long as the temperature stays below 80°C, you have nothing to worry about. Subsequent backups will also run up the CPU, but not for nearly as long.
The CrashPi: Secure, off-site backups
Now we come to the real payoff, and the part that’s going to keep your stuff safe in the event of a fire or flood. When you use CrashPlan to back up to another computer, that other computer does not have to be on the same local network as the computer it’s backing up. It can be anywhere on the internet. It could be on the other side of town, or in a different state.
A Raspberry Pi is cheap enough that you could just Velcro one to the side of a big USB drive and leave the whole thing at a buddy’s house. If your buddy does the same, and parks a CrashPi (as I am now calling it) at your house, then you’ll both be protected in the event of a disaster… unless, of course, you live in the same apartment building. You should choose a location for your off-site backups that is far enough away that both sites are unlikely to fall victim to the same disaster.
To build a CrashPi, all you need to do is build another Raspberry Pi Home Server, leaving out all the parts that CrashPlan doesn’t need, which is actually most of them. Follow this subset of the Raspberry Pi Home Server blog series, and you’ll have made a CrashPi.
- Installing the OS:
Start with a small, cheap SD card. You only need 4GB.
- Configuring the OS:
If you want SSH access to maintain the CrashPi remotely, your buddy will have to punch a hole in the firewall, or put the CrashPi in his/her DMZ.
- Web Administration: (Optional)
This will let you check in on your CrashPi to perform maintenance, install updates, etc.
Your buddy will have to punch a hole in the firewall, or put the CrashPi in his/her DMZ.
- This post:
You may have noticed something CrashPlan calls a “backup code”. This is a unique code that identifies a specific CrashPlan installation. You can give this code to a friend to let them back things up to your server, even though you have different accounts. For instance, when the kids head off to college, you might want to let them use your Raspberry Pi Home Server as a backup destination. All they’ll need is that particular computer’s “backup code”, which you can get from “Friends” tab in the CrashPlan UI.
As far as core home server functionality goes, the Raspberry Pi is already doing a lot. It’s sharing files and media on the local network, downloading things for you, and backing up your computers, even over the internet when you’re away from home.
What more could you possibly want?
How about Virtual Private Networking (VPN) access to your home network when you’re away? Sound good? In the next post, we’ll set up OpenVPN so that you can have all the safety and security of your home network, even from the sketchiest of airport coffee shop networks.
I have a sneaking suspicion that this article is going to see more updates than most, so I’m starting a section here at the bottom to catch any updates.
CrashPlan UI has stopped working!
If you have already installed CrashPlan in the past, and find that the UI doesn’t work anymore after performing an apt-get update/upgrade, you’ll need to repeat the final step of the article once again to put things back to normal. Simply run the following commands to replace the SWT library that CrashPlan installs with one that is compatible with the Pi, and you should be up and running again.
sudo cp /usr/lib/java/swt-gtk-3.8.0.jar /usr/local/crashplan/lib/swt.jar
You may need to do this each time you do an apt-get update/upgrade, unfortunately. I haven’t quite figured out what causes the problem just yet, but since CrashPlan wasn’t installed through apt-get, that shouldn’t be it. Just remember this in case your UI stops working one day.