Raspberry Pi + Crashplan

There are lots of posts about java, and quite a few on Crashplan on embedded systems. But even despite people’s efforts to aggregate all the little information, I just lost a weekend to this project. If you’re frustrated by the “backup disabled — not available” error, you’ve come to the right place.

This guy is really close – and it’s easily the only complete guide to crashplan on raspberry pi that actually works (until now). However, it uses openjdk, which, if you won’t trust my experience, these benchmarks show is PAINFULLY slow. Surely we can do better.

So, let’s try Oracle’s Java. To save time, we’ll jump forward to the Java 8 preview which has hardware floating point support (also hard-float or hard abi). So, step by step, with generous acknowledgments to Jon Rogers:

  1. Set up the Raspberry Pi. You want the hard-float OS unless you like an older version of java for some reason (and in that case, see Rogers for the correct libjtux.so)
  2. Get Java (Note to future: If Oracle has released a newer version, you should use that instead)
  3. Extract the archive (tar -xf [archiveName]) (Note: Oracle’s being dumb – they wanted .tgz, not .gz)
  4. Copy the archive somewhere. People seem to like /opt, so I moved mine there
  5. change to superuser su (note: if you haven’t set a root password yet, do so with sudo passwd
  6. add java to your path. For me, this was export PATH=$PATH:/opt/jdk1.8.0/bin
  7. Download crashplan and extract it
  8. Run the crashplan installer (Crashplan-install/install.sh). I’ll assume that you installed to the default /usr/local/crashplan/. If you get an error “The current version of Java (1.8) is incompatible with CrashPlan”, edit install.sh and change OKJAVA="1.5 1.6 1.7" to OKJAVA="1.5 1.6 1.7 1.8"
  9. exit (leave root and go back to your user)
  10. Download the patched libjtux and md5 library. Extract as necessary and copy the .so files to /usr/local/crashplan/
  11. sudo apt-get install libjna-java
  12. edit /usr/local/crashplan/bin/CrashPlanEngine and find the line that begins with FULL_CP=
    (its around the start case)
    add /usr/share/java/jna.jar: to the begining of the string. Thanks to Torbjörn – this gem too me forever to find. This fixes the cryptic “backup disabled — not available” error.
  13. Autostart the crashplan engine. Edit /etc/rc.local with your favorite editor, and add /usr/local/crashplan/bin/CrashPlanEngine start on the line above exit 0.
  14. restart (sudo shutdown -r now)

If everything worked, “/usr/local/crashplan/bin/CrashPlanEngine status” should show running, and you should be able to connect via crashplan’s headless client guide. Finally :)

UPDATE:
You should take a look at Brad Peterson’s comment below when you inevitably run into periodic crashes from insufficient memory. Thanks for the tip!

About Bion

I'm a software developer at Modo Payments, a mobile payment provider. When I'm not hacking away the office, you I'm usually at home hacking on something else. Or practicing Aikido. Anyway, I just post things here that Google couldn't help me with, so maybe it'll help you in the future. Since you're reading this, I guess it worked :)
This entry was posted in Technology. Bookmark the permalink.

44 Responses to Raspberry Pi + Crashplan

  1. dhead666 says:

    Thanks for this great post.
    Based on your & Jon Rogers’ posts I written a guide how to get CrashPlan on Arch Linux.
    http://archlinuxarm.org/forum/viewtopic.php?f=31&t=5120

  2. Brad Peterson says:

    I’m not having success with this approach. My crashplan server seems to quietly crash within a half hour or so of startup. I’ve tried all sorts of things, moving to a different USB hard drive and file type, updating to the newest firmware, building my own libmd5.jo and libjtux.so. Nothing is doing the trick.

    With all the newest updates, I can say it’s *much* faster than it was before. But those random silent crashes is making it unusable. My only guess is that the Java 8 preview isn’t perfect yet?

    I think I’ll reinstall with an older Java for now and give that a try.

    • Bion says:

      Well, the approach technically did work – you’re running Crashplan with Java 8 on the pi and it’s doing something. I think it’s Crashplan’s fault for not doing something reasonable, but they don’t seem to care much. My experience with Crashplan on my mac is that random, periodic crashes (particularly during things like file scans) are a result of Java being out of memory. One would think that 512mb of RAM would be more than sufficient, but do not underestimate the incredible inefficiency of the JVM. (Note: You can complain to crashplan, but your plees will fall on deaf ears). Crashplan’s (unofficial) recommendation is to either increase Java’s memory size (which you can’t really do on the Pi. Heaven help you if you’re on the A model…), or to reduce the number of files being backed up. It starts hating on me around 1.25 million files.

      However, if you’re connecting to an existing backup archive and are crashing during the “Verifying Files (deep)” phase, I’m sorry, I really do wish I could help you, but I didn’t get any further than you. It’s possible there’s a memory leak somewhere in the Java 8 preview… I was seeing a lot of memory pressure with CIFS too, so it might be too network intensive for the pi? I don’t know. You could try going back to the soft ABI with Java 7. It’ll be slower, but it’ll still be significantly faster than openjdk. I don’t know if that’ll actually solve anything, but please post your results. As for me, I’ve given up on the pi, and I’m working on running Crashplan directly on a FreeNAS server. Hopefully I’ll have a post on that in the next few weeks…

      • Brad Peterson says:

        I got it figured out! Came here, and it seems you were on the right track too. Java 8 + CrashPlan uses too much memory. There’s a way to fix this though. I also outlined all the other tweaks I did to make this thing really fast.

        In my /var/log/messages, I noticed this right before CrashPlan did a silent crash:

        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268175] java invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268278] [] (unwind_backtrace+0x0/0xf0) from [] (dump_header.isra.15+0x74/0x1a0)
        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268333] [] (dump_header.isra.15+0x74/0x1a0) from [] (oom_kill_process+0x294/0x418)
        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268363] [] (oom_kill_process+0x294/0x418) from [] (out_of_memory+0x1cc/0x29c)
        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268412] [] (out_of_memory+0x1cc/0x29c) from [] (__alloc_pages_nodemask+0x608/0x63c)
        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268444] [] (__alloc_pages_nodemask+0x608/0x63c) from [] (filemap_fault+0x250/0x47c)
        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268475] [] (filemap_fault+0x250/0x47c) from [] (__do_fault+0x6c/0x4a0)
        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268501] [] (__do_fault+0x6c/0x4a0) from [] (handle_pte_fault+0x74/0x788)
        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268526] [] (handle_pte_fault+0x74/0x788) from [] (handle_mm_fault+0x98/0xc8)
        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268556] [] (handle_mm_fault+0x98/0xc8) from [] (do_page_fault+0x29c/0x3ec)
        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268600] [] (do_page_fault+0x29c/0x3ec) from [] (do_PrefetchAbort+0x34/0x98)
        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268626] [] (do_PrefetchAbort+0x34/0x98) from [] (ret_from_exception+0x0/0x10)
        Mar 2 17:52:23 raspberrypi kernel: [ 1820.268640] Exception stack(0xca9ddfb0 to 0xca9ddff8)

        Seems I ran out of RAM, and out of swap space, and the Linux oom-killer noticed a severe drop in performance and kept killing my CrashPlan server.

        I never got this oom-killer problem under an older Java. Seems Java 8 uses just enough memory to push me over the edge. And I’m running on an older Raspberry Pi model B (purchased summer 2002), they are stuck at 256 MB of RAM. Newer model Bs go to 512 MB of RAM (a HUGE help!)

        So, I did some tweaking. I would assume other Raspberry Pi owners should do this too if they notice a similar problem. (I’d recommend everyone just do it anyway, it will make their setup run faster and longer.)

        (Note, if anyone is doing any tweaking, it helps to be on the newest firmware, it helps considerably. I was on an older one, and I noticed performance increases by updating it. There are guides online how to update that. One good option is here: https://github.com/Hexxeh/rpi-update).

        First, I gave my Raspberry Pi more memory via swap space. Ya, swap space is typically very slow, but for backup purposes, it’s fast enough. Since I have a removable USB drive attached to my Raspberry Pi, I created swap space there. (Do all these as root or under sudo).

        Run this once for initial set up (my /path/to/swapfile is on my USB drive):

        dd if=/dev/zero of=/path/to/swapfile bs=1M count=1024
        mkswap /path/to/swapfile
        chown root:root /path/to/swapfile
        chmod 0600 /path/to/swapfile

        Before you start that swap, see what swaps you already have:

        free -h

        I think most Raspberry Pi owners will see 100 MB listed in there. That’s a bad idea (I’ll explain why), and we’ll remove it. But for now, lets just add on more swap:

        swapon /path/to/swapfile

        See if it worked:

        free -h

        If you have an extra 1 GB of swap space, you’re in luck! Now make this permanent on reboots:

        vi /etc/fstab

        After your removable drive has been mounted, add this:

        /path/to/swapfile swap swap defaults 0 0

        Save and exit vi. Then restart the machine with “reboot”. On reboot, run “free -h” to see if you still have your new swap space. It may list 1.1 GB, if there are 100 MB from the first swap and 1 GB from the swap you just made.

        Lets get rid of that 100 MB swap. It’s a bad idea for us. Java + CrashPlan frequently uses the swap file. That’s not good for SD drives, too many writes and the SD card gets used up. And it seems Rapsberry Pi comes with 100 MB of swap file by default on the SD drive. I noticed that mmcqd process was hitting around 35% CPU time when it was using swap space. Yuck! SD card swap space is a bad idea for both the SD card and the CPU.

        So stop the Raspberry Pi from creating swap on the SD card:

        sudo apt-get purge dphys-swapfile

        Run “reboot” again. Then do a free -h to confirm you have 1 GB of swap space where you need it. That should do it. The oom-killer shouldn’t silently kill CrashPlan anymore because there’s extra room in memory. And it should go faster without mmcqd hogging the CPU time. And your SD card should last much longer.

        One final tweak. The Raspberry Pi can be overclocked. Run as sudo or root:

        raspi-config

        Then go down the overclock option. I put mine on the second to last option. (The last option made my machine lock up). If it doesn’t work for you, there’s instructions on how to fix it back online. I definitely noticed a further performance boost after doing this..

        • Brad Peterson says:

          It seems that overclocking now causes problems, I would now advise against it. I was getting some funny ext4/filesystem errors similar to this:

          EXT4-fs error (device mmcblk0p2) in ext4_reserve_inode_write:4550: Journal has aborted

          Most of the time I was unable to reboot the machine. I could do an fsck on another Linux computer, it reported hundreds of errors, and then it refused to boot any further.

          After much trial and error, I believe the cause was the overclocking. I ran raspi-config, ensured it is at normal levels (not 950 MHz as before). Now it has been running smoothly again for hours without issue.

      • Brad Peterson says:

        Just an update, on a local network, I’m getting 55 Mbps receiving from a computer to my raspberry pi, and ~40 Mbps sending to another computer. My CPU is now maxed out. Swap space gets as high as 200 MB.

        One problem I noticed is that trying to have both computers do full send and receives at this rate bogs it down, down into the single digit Mbps range. Swap space gets up to 250 MB trying this. So, there is a limitation here, just don’t expect to be able to do full send/receive backups using an older Raspberry Pi. I would hope that a new model raspberry pi with 512 MB of RAM could avoid the swap space, and do this much faster.

        Overall, this is still a huge, HUGE improvement over the speeds I saw before. I was getting far less than 1 Mbps under the old Java approach.

  3. David says:

    Hi all. Thank you so much for all the information above. I used it all and with some minor mods got it all working. Still now sure about the stability of it all, but have some suggestions to follow on that.

    The basic procedure does work. Critical step is the switch to root and adding the path statement. It did however cause some issues first time around as the install would not see the java environment. I then played around a little bit and found another option.

    Don’t worry about the path and run the crash plan install. It will then request to install the Java 6 jre into the crashplan directory. I let it do this. Then removed that directory and copied over the Java 8 jre to the same location.

    Along side all the other updates and new files from the above post that worked a treat and crashplan is running.

    I next ran into a problem that I was getting corruption off my SD card. Now that might be the card I was using. My other setup card of owncloud with deluge works fine (I’m waiting for my second Pi to arrive). thought it might be trying to overclock to modest, not sure.

    What I have done is follow some guides for moving the fsroot off to the usb drive. Took some trial and error. Using a minimal 2gb card i was going sweet until i upgraded the firmware, suspect that might be because the boot partition was read only when i did that.

    But the great news was I had already moved all the fully configured rootfs to the USB drive. I now have on it:
    /dev/sda1 for the swap
    /dev/sda2 for root
    /dev/sda3 for data

    I reformated the SD card to basic os. Logged in. Then did and apt-get update
    followed by the firmware update install. System rebooted perfect. Walked my SD card back to the windows pc. Updated cmd file and reboot. Hello my old system is back!!

    Now going to be testing the stability of it as I my current server sucks huge amounts of power and the PI solution for crashplan (I have other locations backing up to me) could well be the answer to lower power bills.

    I have found so far that by creating a swap file and putting the fsroot onto the USB drive is looking really good. Still working out the settings on the swap file. I’ll put together a full guide shortly on it.

    Huge thanks to the great community of pi users. Its been a collection of different articles from people and its so cool working with this system and learning what people are doing with it.

    • Brad Peterson says:

      Heh, I saw the same problem with Java. It kept recognizing my Java 6 install instead of my Java 8. I had to remove my original Java 6 installation. I found this command to do the trick:

      sudo apt-get purge openjdk-\* icedtea-\* icedtea6-\*

      Also, as for stability on my end, I’ve run mine continually for the past three weeks without any problems. It’s low power, quiet, and now acts solid as a rock.

  4. Ian says:

    Great guide.

    I also had some stability issues until I switched to ext4. I’d been lazy and used an NTFS drive I had lying around. A bonus is that the backup rate has doubled!

    Something I spotted when trying to work out the issues: libmd5.so isn’t being used by default in Crashplan 3.5.2: you need to modify run.conf to set the c42.native.md5.enabled to true.

    Also, I’m using a 512MB Pi and have half the memory still free while Crashplan is running.

    • Ben P. says:

      I was getting all the way up to the part where I had crashplan running headless, but when I went to put in my credentials I got a “Unable to connect check your network” error. I checked various logs and found “java.lang.UnsatisfiedLinkError: /usr/local/crashplan/libjtux.so” and “java.security.ProviderException: setSeed()” errors in /usr/local/crashplan/log/service.log.0 . I was able to resolve some errors by setting c42.native.md5.enabled to true in /usr/local/crashplan/bin/run.conf . The tough error to resolve was the “java.security.ProviderException: setSeed()” error (check with “cat /usr/local/crashplan/log/service.log.0 | grep setSeed()” to see if you have these errors), which I was able to resolve by adding “-Djava.security.egd=/dev/random” to /usr/local/crashplan/bin/run.conf and restarting crashplan. Once this option was added I no longer got the “check your network” error.

  5. Nakej Hrabe says:

    I’ve downloaded java and extracted to /opt, exportet path as root, but CrashPlan install.sh gives me following error:
    No Java VM could be found in your path
    Would you like to download the JRE and dedicate it to CrashPlan? (y/n) [y]

    java -version:
    java version “1.8.0-ea”
    Java(TM) SE Runtime Environment (build 1.8.0-ea-b36e)
    Java HotSpot(TM) Client VM (build 25.0-b04, mixed mode)

    which java:
    /opt/jdk1.8.0/bin/java

  6. Nakej Hrabe says:

    After Crashplan installation I get SD card write error in cca 2 hours intervals:
    dmesg:
    [ 302.569535] EXT4-fs (mmcblk0p2): error count: 2
    [ 302.569565] EXT4-fs (mmcblk0p2): initial error at 1365969698: ext4_remount:4584
    [ 302.569581] EXT4-fs (mmcblk0p2): last error at 1365969735: ext4_remount:4584
    [36046.897283] mmc0: Timeout waiting for hardware interrupt – cmd25.
    [36046.901223] mmcblk0: error -110 transferring data, sector 170656, nr 24, cmd response 0x900, card status 0x0
    [36046.901735] end_request: I/O error, dev mmcblk0, sector 170664
    [36046.901757] end_request: I/O error, dev mmcblk0, sector 170672
    [36046.911910] Aborting journal on device mmcblk0p2-8.
    [36046.914573] EXT4-fs error (device mmcblk0p2) in ext4_reserve_inode_write:4550: Journal has aborted
    [36047.476950] journal commit I/O error
    [36047.492303] EXT4-fs error (device mmcblk0p2): ext4_journal_start_sb:349: Detected aborted journal
    [36047.492339] EXT4-fs (mmcblk0p2): Remounting filesystem read-only
    [36047.496455] EXT4-fs error (device mmcblk0p2): ext4_journal_start_sb:349: Detected aborted journal
    [36048.136254] EXT4-fs error (device mmcblk0p2) in ext4_reserve_inode_write:4550: Journal has aborted
    [36048.136400] EXT4-fs error (device mmcblk0p2) in ext4_reserve_inode_write:4550: Journal has aborted

    Could it be insufficient memory related or it SD card HW failure?
    Thanks!

    • Nakej Hrabe says:

      Confirmed on second SD card. It seems not to be HW related.

      • Brad Peterson says:

        Just a shot in the dark, but…have you watched your swap space? Crashplan can hit the swap space, and if it does, repeated writes to your SD card can ruin it. That’s why I moved my swap space off the SD card and onto my removable USB drive.

  7. Graeme Porter says:

    Still struggling with the infuriating “Backup disabled – not available” issue.

    My Pi has a 1.5 TB external USB hard drive attached. It has three partitions on it – a 32 GB partition for the Pi to boot from (/dev/sda1), a 4 GB swap partition (/dev/sda2), and a partition with all remaining space is available for Crashplan to back up to (/dev/sda3).

    The Crashplan partition is mounted as /crashplan

    I found I didn’t have jna.jar in /usr/share/java/ – or anywhere else on my Pi – so I grabbed it from https://github.com/twall/jna and put it in the /usr/share/java/ folder and restarted the Crashplan service. But it still doesn’t work.

    The weird thing is that it kind of does – occasionally one of my three clients will connect and begin backing up, and will get all the way through the backup – but most of the time it just sits there (for days, sometimes) with “Backup disabled”.

    The Pi itself also doesn’t seem to start its own backup – it just sits with “Waiting for backup”, and if I hit the little “Play” icon to the right of the progress bar, nothing happens. In the “History” panel, it says:

    [Default] Backup to crashplan will take priority until complete (up to 24 hours)

    However, unlike the LAN-connected clients, it doesn’t back itself up at all.

    • Brad Peterson says:

      Just a double check for simple stuff. Did you try the telnet tricks to make sure it can even connect at all? In the past I’d get this message, and it turns out the other end had a firewall which was preventing a connection from occurring.

      • Herb says:

        Graeme: have you worked out the problem in the meantime? I have exactly the same behaviour. Most of the time the raspberry just sits there and says “backup disabled – not available”. Yet every now and then it starts connecting and the backup actually happens and works fine.
        The Pi itself does not backup at all, just says “Waiting for backup”.

        So I am still stuck with the problem “not available”. Anybody worked out what to do?

        Otherwise: Brad and Bion: thanks for your work, would not have been able to figure it out myself.

        • Herb says:

          Ok figured it out. I can’t believe it. I just had a typo in the /usr/share/jave/jna.jar addition in CrashPlanEngine described by Brad above. Now it works like a charme. Thanks again for the writeup.

  8. Nate says:

    Excellent walk through, thanks! I have it fully setup. On the attached backup USB drive, I did a full Crashplan backup when the USB drive was connected to my Win8 desktop to save time. With the USB drive now connected to the RPi, when I do “Attach a backup archive”, I get “backup engine does not have access to the given location”. I tried chmod 755 -R to the backup directory and that didn’t work. Has anyone dealt with this error?

    I may just scrap the archive and take a fresh backup of my Win8 desktop over the LAN to the RPi (it will take a long time though). Once the full is done, I plan to move this RPi setup to a friend’s place.

    • Nate says:

      I ran into this error since the partition was NTFS. I ended up creating 2 ext4 partitions on the USB drive with 1 for the swap Brad recommended and 1 for backups. I am have kicked off a new backup and it is going at about 15-20 Mbps.

  9. Marvin says:

    I’m having problems with the headless-client-setup and I’m not sure if my crashplan is working correctly:
    I’m using the recent version of raspbmc.
    When I open the ssh tunnel and start my crashplan on the desktop the ssh shell outputs several times “channel 2: open failed: connect failed:” until the crashplan GUI comes to the conclusion that is could create a connection.

    Here is the content of the engine_output.log and the results of netstat: http://lpaste.net/90870

  10. Rex Vokey says:

    Hey — just wanted to say “thanks!” It’s nice to have a how-to all in one place.

  11. Omri says:

    after this announcement:
    http://www.raspberrypi.org/archives/4920
    which java version should i choose?
    thanks!

    • Bion says:

      Awesome! Yeah, use that

      • Uzi says:

        Can you confirm it is working? I think I’ve done every required step (changing the path was not necessary, oracle java came as standard in /usr/bin/)

        I’ve problems with the headless configuration:
        service seems to be active:
        pi@raspberrypi ~ $ ps -ef | grep crash
        root 1956 1 0 10:47 ? 00:01:32 /usr/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx512m -Djava.net.preferIPv4Stack=true -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false -classpath /usr/share/java/jna.jar:/usr/local/crashplan/lib/com.backup42.desktop.jar:/usr/local/crashplan/lang com.backup42.service.CPService

        pi@raspberrypi /usr/share/java $ netstat -an |grep -E ‘(4243|4242)’
        tcp 0 0 0.0.0.0:4242 0.0.0.0:* LISTEN
        tcp 0 0 127.0.0.1:4243 0.0.0.0:* LISTEN

        The telnet test is still not working (trying from the PI locally or remote doesn’t matter)
        Trying 127.0.0.1…
        Connected to localhost.
        Escape character is ‘^]’.

        but I don’t get any response

  12. Pingback: Crashplan backup to my Raspberry Pi | Chex

  13. Greg Aldrich says:

    I have this working on a Raspberry Pi Model B. Started with the NOOBS 8G SD Card. I used information from above, the Oracle Java 1.7 post, and several other pages to build a Pi with 1TB WD Passport attached. My MacBook Air has been backing up to it for over an hour so far with no issues. Many thanks to Jon Rogers, Bion, Brad Peterson, and others for contributions toward getting this done.

    I am posting my documentation which sections just duplicate some of the above post and comments. There are some differences and I also document setting up the USB drive, etc. all in one place in case it helps someone. Rather than use a variable like path/to/swapfile, I use the real names in case someone will benefit from an actual example. Make sure you adjust accordingly.

    CrashPlan (headless) on Raspberry Pi

    Using the NOOBS v1.2.1 SD on a B Model with 512Mb
    Using a WD MyPassport 1TB NTFS USB Drive formerly on a Windows 7 box

    Install Raspbian (default selection in NOOBS)
    The unit will boot into raspi-config, choose option 8, advanced options
    Choose option A5, Update this tool to the latest version

    Set Keyboard, Locale, and Timezone if not UK:
    Choose option 4, Internationalization Options
    Choose I1, Change Locale, and follow the prompts (e.g. en_US.UTF-8 UTF-8)
    Choose I2, Change Timezone, and follow the prompts
    Choose I3, Change Keyboard, and follow the prompts

    Optional, set host name (good if you have multiple units):
    Return to option 8, advanced options
    Select A2, Hostname

    Optional, overclock the unit:
    Select option 7, Overclock
    Select Modest for a 14% boost in MHz with no overvolt to start or no overclock. Get it working first so you know if the overclock is the culprit if you have problems.

    Select Finish when done with configuration options and allow a reboot.

    Install GIT (in case the newest version is not installed – mine was up to date):
    sudo apt-get install git-core

    Install Update Tool (in case the newest version is not installed – mine was up to date):
    sudo apt-get install rpi-update

    Upgrade Firmware (this can take some time):
    sudo rpi-update

    Check Firmware (mine was June 17 2013 20:49:11):
    sudo vcgencmd version

    Reboot:
    sudo reboot

    Recheck Firmware (mine was Jan 10 2014 16:58:06):
    sudo vcgencmd version

    If you haven’t already, mount your USB drive.

    Find your drive’s location:
    sudo dmesg

    I found the entries associated with the drive as it came up “Direct-Access WD My Passport...

    Following this down, I can see it is sda: sda1

    If necessary, format the drive, ext4 is recommended:
    sudo mkfs.ext4 /dev/sda1 -L cpusb01

    To mount the USB drive, create a directory in mnt:
    sudo mkdir /media/usbhd

    Mount the directory:
    sudo mount -t ext4 /dev/sda1 /media/usbhd

    If no errors, you should be able to do a directory listing on the mounted volume:
    ls -l /media/usbhd

    Note: to unmount the drive (before unplugging) issue the following command:
    sudo umount /media/usbhd

    Since I plan to leave this drive attached as a primary backup volume, I want to automount it on reboot. Because I may add more USB drives in the future, the safest way to mount the drives is using its Unique Identifier (UUID).

    To find the UUID, enter this command:
    ls -laF /dev/disk/by-uuid

    This gave me the following (this drive only):
    F474B7AA74B76DCC -> ../../sda1

    I then modify /etc/fstab to mount this drive automatically:
    sudo vi /etc/fstab

    I append this line:
    UUID=F474B7AA74B76DCC /media/usbhd ntfs nofail,user,auto,rw 0 0

    After saving and quitting (:wq), I test it manually by first unmounting:
    sudo umount /media/usbhd

    And then mounting with:
    sudo mount -a

    This mounts the drive using the entry in /etc/fstab.

    Test to be sure:
    ls -l /media/usbhd

    Thanks to Brad Peterson (above): Raspbian by default will have 100MB swap on the SD card. This is not a good idea. It is small and it will kill the SD card. Since we have an external USB drive attached as backup media, we will use this for swap instead.

    Initial setup (the first command may take a while with no feedback, be patient):
    sudo dd if=/dev/zero of=/media/usbhd/swapfile bs=1M count=1024
    sudo mkswap /media/usbhd/swapfile
    sudo chown root:root /media/usbhd/swapfile
    sudo chmod 0600 /media/usbhd/swapfile

    Add the additional swap space just created (takes a while as well):
    sudo swapon /media/usbhd/swapfile

    Verify the additional swap space:
    free -h

    This should now report 1.1G

    Now we make it mount at boot time.
    sudo vi /etc/fstab

    Insert the following after the USB mount:
    /media/usbhd/swapfile swap swap defaults 0 0

    Reboot and see if it is still 1.1G
    sudo reboot
    free -h

    Now to stop Raspbian from creating the 100M swap on the SD card:
    sudo apt-get purge dphys-swapfile

    Reboot again and validate only 1G of swap:
    sudo reboot
    free -h

    Now on to installing Java. We are going to try Oracle Java since it offers significant performance advantages over OpenJDK on ARM platforms. Courtesy of eben at http://www.raspberrypi.org/archives/4920.
    sudo apt-get update && sudo apt-get install oracle-java7-jdk

    Download CrashPlan for Linux and extract it:
    tar -xvf CrashPlan_3.5.3_Linux.tgz

    Install CrashPlan (important: install as root and from the CrashPlan-install directory – I got several errors trying to run it using Crashplan-install/install.sh):
    su (if you haven't set the root password, use sudo psswd)
    cd CrashPlan-install
    ./install.sh
    exit

    ** Make sure you change the default backup directory to /media/usbhd/crashplan/

    Start the CrashPlan Engine:
    sudo /usr/local/crashplan/bin/CrashPlanEngine start

    Validate it is running:
    /usr/local/crashplan/bin/CrashPlanEngine status

    It will crash because libtux.so included by CrashPlan is compiled for 32-bit Intel which will not run on an ARM processor. Here is the fix:

    Download the patched libjtux and md5 library, courtesy of Jon Rogers.
    Extract as necessary and copy the .so files to /usr/local/crashplan/ replacing the files that are there.

    Then:
    sudo apt-get install libjna-java

    Now, per Bion's post, edit /usr/local/crashplan/bin/CrashPlanEngine and find the line that begins with FULL_CP= (its around the start case) add this to the beginning of the string:
    /usr/share/java/jna.jar:

    Start the CrashPlan Engine again:
    sudo /usr/local/crashplan/bin/CrashPlanEngine start

    Validate it is running:
    /usr/local/crashplan/bin/CrashPlanEngine status

    Next we move on to running a remote client. I am not going to detail this since CrashPlan has it detailed on one page here:

  14. Greg Aldrich says:

    I have multiple edits for this commentary.

    For the formatting of the USB drive, I had an old volume name in there as I ran through this process twice. Where I wrote:

    sudo mkfs.ext4 /dev/sda1 -L cpusb01

    The cpusb01 should be usbhd to be consistent with the rest of the document or this will look like it’s working but will fail once you start backing up (because your swap and backup location will be on the SD card).

    That line should read:

    sudo mkfs.ext4 /dev/sda1 -L usbhd

    I tested this all again and it worked. I am getting over 80 Mbps right now and I do plan to go back and experiment with overclocking.

    One other thing I found which may be helpful was in:
    /usr/local/crashplan/conf/my.service.xml

    You will find the following line:
    /usr/local/crashplan/cache

    I edited mine to:
    /media/usbhd/crashplan/cache

    If it is a fresh install, that is it. If you already have a cache built up, you will want to move that before you restart the service.

    The same goes for the log files. You will find “/usr/local/crashplan/log/xxxx.log” entries in my.services.xml as well.

    Finally, the headless client link was missing a quotation mark. The last sentence should have read:

    Next we move on to running a remote client. I am not going to detail this since CrashPlan has it detailed on one page here.

  15. Tobias Böhm says:

    Thank you very much for your excellent description!

  16. Great ,
    doing something somewhat like yours. If I get it off the ground I’ll try and remember to come back to this page to find out any news.

  17. Pingback: Creating a personal file synching service with OwnCloud and Crash Plan | Dude! My Dad's a geek!

  18. Andrew Moylan says:

    Thanks @Greg Aldrich! Those are the most up-to-date instructions I’ve seen for the latest versions of Crashplan & Raspian. I got everything working using those.

  19. Pingback: Headless Crashplan en Cubietruck (Cubian) « imanzano.es

  20. Ignacio says:

    Awesome! I have used this information to install Crashplan on a Cubietruck (cubieboard 3). Thank you very much.

  21. Jonathan Greenberg says:

    Thanks for these great hints. I’m down to a small problem that I haven’t gotten solved. I’d like to use Crashplan to backup to my NAS, which has a Public directory mountable via Samba. Thus far, I’ve managed to get it mounted, but something is screwy with the permissions (I can create files via the mount, but CrashPlan is not able to write any files to it). Any ideas on this? Here is the fstab entry:

    //IPofNAS/Public /home/pi/NASmount cifs guest,rw,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0

  22. Pingback: Raspberry Pi Home Server: Part 10, CrashPlan | MelGrubb.ToBlog()

  23. Pingback: Raspberry Pi Home Server: Part 10, CrashPlan | MelGrubb.ToBlog()

  24. Stu Jordan says:

    Thanks Bion. Just upgraded my pi from JRE 6 to 8 and my download speeds changed from 300kbps to 3.3Mbps! My CPU also dropped from a pretty persistent 100% to around 80%.

  25. Stu Jordan says:

    hmm actually make that 9.5Mbps. Thanks a million.

  26. Dan says:

    Well over a year after this guide was published here is something I could not solve but may help someone.
    I spent ages trying to figure this out, It tried it again and again, I did a reinsatall of everything, compiled the files myself, you name it I tried it and I am still stuck at a point where it just says Backup Running but never actually backs up.
    I have come to the conclusion that it is something to do with the database of all my backed up files being to large ( I have over 7tb backed up to crashplan central). However when I created a fresh account to test it has backed up fine and so far has backed up about 300gb and several TB to local HDDs.
    So if you come across the same problem as me you are not alone. If anyone knows how to fix my problem please let me know
    I also tried it on a Banana Pi as it has a faster CPU and 1gb but I had the same problem.

  27. Relnah says:

    Adding some info that fixed a problem when using 4.3.0 of Crashplan.
    A GUID/key has been introduced and you need to copy the GUID from your headless installation (RPi) to the client installation where you are connecting from.

    I’m running on a RPi 2.

    GUID fix found here: http://chrisnelson.ca/2015/07/02/fixing-crashplan-4-3-0-on-synology/

    Guides I followed to get it working (including this one):
    relnah.blogspot.se/2015/07/headless-crashplan-on-raspbery-pi-2.html

Leave a Reply

Your email address will not be published. Required fields are marked *