I debated with myself a little as to whether to post or not to post. What the heck … could save you countless hours of fun trying to figure out how to do it yourself ...
Rationale
The thing I like about ARM devices is that they seem to run forever without crashing on virtually no electricity at all, on virtually fresh air. Backing up files into CrashPlan takes a lot of time on a slow internet connection, and I don't want my desktop PC running 24/7 for months on end drawing up to 200 watts and wearing out my hard drives and SSDs
So the answer, setup my cloud backup on a lower powered machine, like the Odroid C1 I bought recently.
This guide should be applicable to other devices like the Raspberry Pi and some of the higher spec devices talked about on this forum like NSA320. The issue with CrashPlan is that the more GBs you back up, eventually the more memory you need. CrashPlan's site recommends at least 1GB of RAM. Now that isn't entirely the minimum necessary, it will run with less, but you may run into issues if you want to back up massive archives on a machine with only 128Mb of RAM ... It might work with some tinkering, it might not, up to you to try it out !
Also ARM hardware isn't supported by CrashPlan. So anything here should be considered “experimental”, but this is a hardware hacking forum, so goes with the territory.
There are plenty of guides on how to put CrashPlan onto ARM, I did one myself on this forum a while back for my GoFlexNet. Problem is CrashPlan keep changing things and I think some of the people who write guides forget steps they take – I've done it myself. And there's variances between hardware platforms and setups. So, sometimes you'll follow a guide and it won't work. Solution – keep it simple as possible.
Basically, CrashPlan is shipped for linux to run on Intel or AMD hardware. In order to run it on ARM we need to “customise” the CrashPlan install.
I decided to go with Java 8, because I heard CrashPlan will run with it, and it's supposed to have a lot of performance enhancements. Odroid C1 is a armhf (rather than armel) processor. Basically the difference is armel does software floating point calcs and armhf has a hardware processor for them, or at least that's the way I understand it. Raspberry PI is also armhf, so the .so files I found for Raspberry PI seem to work OK on Ordoid too. If in doubt, best to compile your own. It's only JTUX that you might need to compile, and that has to be patched for ARM.
A lot of the guides go on about providing a native md5 library, fast-md5 and libmd5.so … I'm not convinced that this is necessary, obviously you're welcome to compile your own and use it, but I've omitted this step because it adds additional complexity, and by default CrashPlan has native md5 switched off. It's possible that java 8 has a better performing md5 anyway. Perhaps someone will do an in depth performance study, me, I haven't got the time !
Also of note is that I'm running CrashPlan “headless”, that is without a monitor attached or a graphical display installed on my server. I did this because I don't really need the “bulk” of installing GNOME or XFCE, and I will administer it "remotely". So there's a little bit of messing around in order to access from a laptop or desktop machine ...
Assumptions – Debian Jessie / ARM (like Odroid C1, RPi, NSA320) Device / user = root / Some of your own working brain cells !
STEP 1 – Install Oracle Java 8
The Debian wheels turn very slowly, they are also precious about including closed source stuff like Oracle Java. So, we need to “grease the wheels”. Best/easiest way to do this is add the webupd8team's Ubuntu repository to Debian and install Oracle Java 8 that way
I #'ed out the deb-src line because I've never read any of the source code I downloaded, and would fetch it manually if I needed it … if you want it then add it back in.
And run a :
That'll confirm it's been installed correctly !
(source - http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html )
STEP 2 – Install libjna
You'll need the JNA, Java Native Access library as CrashPlan uses it and the Intel/AMD version won't run on your ARM device.
(source - https://melgrubb.wordpress.com/2014/08/01/raspberry-pi-home-server-part-10-crashplan/ )
STEP 3 – Get CrashPlan installer and install it
CrashPlan update their versions all the time, so you may have to go to their website and dowdload it. At the time of writing this should work :
Now you're in the CrashPlan installer. I answered defaults to all questions, which is the easiest thing to do. It will start CrashPlan automatically, which will fail, so might as well shut down CrashPlan whilst we apply the magic which makes it work
STEP 4 – The MAGIC which makes it work
The essentials are JNI/JNA and JTUX, without them CrashPlan won't work on your ARM device. Plus there's tidying up the mess CrashPlan has made of trying to install the Intel/AMD stuff.
For JTUX I used the Arch Linux .so file, which works fine on my platform. You may want to patch and compile as described here, especially if your architecture is armel - see http://archlinuxarm.org/forum/viewtopic.php?f=31&t=5120 , and you'll need to patch JTUX as described.
Easy way for armhf - RPi / Odroid et al :
(source - http://www.jonrogers.co.uk/2012/05/crashplan-on-the-raspberry-pi/ )
STEP 5 – Tell CrashPlan where JNA is
There's some CrashPlan config files we need to edit …
You need to change :
To
(source - https://melgrubb.wordpress.com/2014/08/01/raspberry-pi-home-server-part-10-crashplan/ )
STEP 6 – Make the CrashPlan server available for remote access (ie headless)
You'll need to change this line :
to
STEP 7 – Start the CrashPlan server
STEP 8 – Connect to the CrashPlan server from your laptop or desktop (ie "the client")
For simplicity I'm assuming a linux desktop or laptop (although the same is possible from a windows machine, just different file locations on windows). You need to download and install the CrashPlan application (AGAIN) on your laptop or desktop. Then modify this file locally :
Uncoment and change this line from :
To
where 192.168.1.233 is the IP address of your ARM CrashPlan server.
NOW THEN, the above used to be enough, BUT it seems CrashPlan have added a new “feature” which took me ages to figure out and was preventing me connecting to my CrashPlan server. They've introduced a token file, which, if the client application (CrashPlanDesktop) doesn't have access to, then you've get an error in your server's service.log.0 file, complaining about the token being invalid. CrashPlan's own guide about headless server connection doesn't even mention this token, so I suspect it's a very new addition.
Fix by :
Then run :
If all went well, then you should be accessing your ARM device's CrashPlan server with the client application on your desktop or laptop.
STEP 9 – A bonus to speed things up
You can certainly dig around in the config file on your CrashPlan server my.service.xml and there's a lot of settings which can be adjusted to suit your needs. Some of these settings are available in the CrashPlan client app too. This one isn't, and hopefully will save you some time …
Rationale – there's really no point in compressing files which are already compressed.
Change the /usr/local/crashplan/my.service.xml file from :
To :
It's also possible to switch off compression globally, but not sure I'd recommend that unless all your files are compressed …
Job done I think …
Enjoy
(PS - If anyone knows how to switch off CrashPlan automatic updates, please could you tell me ! )
Rationale
The thing I like about ARM devices is that they seem to run forever without crashing on virtually no electricity at all, on virtually fresh air. Backing up files into CrashPlan takes a lot of time on a slow internet connection, and I don't want my desktop PC running 24/7 for months on end drawing up to 200 watts and wearing out my hard drives and SSDs
So the answer, setup my cloud backup on a lower powered machine, like the Odroid C1 I bought recently.
This guide should be applicable to other devices like the Raspberry Pi and some of the higher spec devices talked about on this forum like NSA320. The issue with CrashPlan is that the more GBs you back up, eventually the more memory you need. CrashPlan's site recommends at least 1GB of RAM. Now that isn't entirely the minimum necessary, it will run with less, but you may run into issues if you want to back up massive archives on a machine with only 128Mb of RAM ... It might work with some tinkering, it might not, up to you to try it out !
Also ARM hardware isn't supported by CrashPlan. So anything here should be considered “experimental”, but this is a hardware hacking forum, so goes with the territory.
There are plenty of guides on how to put CrashPlan onto ARM, I did one myself on this forum a while back for my GoFlexNet. Problem is CrashPlan keep changing things and I think some of the people who write guides forget steps they take – I've done it myself. And there's variances between hardware platforms and setups. So, sometimes you'll follow a guide and it won't work. Solution – keep it simple as possible.
Basically, CrashPlan is shipped for linux to run on Intel or AMD hardware. In order to run it on ARM we need to “customise” the CrashPlan install.
I decided to go with Java 8, because I heard CrashPlan will run with it, and it's supposed to have a lot of performance enhancements. Odroid C1 is a armhf (rather than armel) processor. Basically the difference is armel does software floating point calcs and armhf has a hardware processor for them, or at least that's the way I understand it. Raspberry PI is also armhf, so the .so files I found for Raspberry PI seem to work OK on Ordoid too. If in doubt, best to compile your own. It's only JTUX that you might need to compile, and that has to be patched for ARM.
A lot of the guides go on about providing a native md5 library, fast-md5 and libmd5.so … I'm not convinced that this is necessary, obviously you're welcome to compile your own and use it, but I've omitted this step because it adds additional complexity, and by default CrashPlan has native md5 switched off. It's possible that java 8 has a better performing md5 anyway. Perhaps someone will do an in depth performance study, me, I haven't got the time !
Also of note is that I'm running CrashPlan “headless”, that is without a monitor attached or a graphical display installed on my server. I did this because I don't really need the “bulk” of installing GNOME or XFCE, and I will administer it "remotely". So there's a little bit of messing around in order to access from a laptop or desktop machine ...
Assumptions – Debian Jessie / ARM (like Odroid C1, RPi, NSA320) Device / user = root / Some of your own working brain cells !
STEP 1 – Install Oracle Java 8
The Debian wheels turn very slowly, they are also precious about including closed source stuff like Oracle Java. So, we need to “grease the wheels”. Best/easiest way to do this is add the webupd8team's Ubuntu repository to Debian and install Oracle Java 8 that way
echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" | tee /etc/apt/sources.list.d/webupd8team-java.list # echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys EEA14886 apt-get update apt-get install oracle-java8-installer
I #'ed out the deb-src line because I've never read any of the source code I downloaded, and would fetch it manually if I needed it … if you want it then add it back in.
And run a :
java -version javac -version
That'll confirm it's been installed correctly !
(source - http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html )
STEP 2 – Install libjna
You'll need the JNA, Java Native Access library as CrashPlan uses it and the Intel/AMD version won't run on your ARM device.
apt-get install libjna-java
(source - https://melgrubb.wordpress.com/2014/08/01/raspberry-pi-home-server-part-10-crashplan/ )
STEP 3 – Get CrashPlan installer and install it
CrashPlan update their versions all the time, so you may have to go to their website and dowdload it. At the time of writing this should work :
wget https://download2.code42.com/installs/linux/install/CrashPlan/CrashPlan_4.3.0_Linux.tgz # Then unpack the file : tar zxvf CrashPlan_4.3.0_Linux.tgz # move into the installer directory cd CrashPlan-install # Install CrashPlan ./install.sh
Now you're in the CrashPlan installer. I answered defaults to all questions, which is the easiest thing to do. It will start CrashPlan automatically, which will fail, so might as well shut down CrashPlan whilst we apply the magic which makes it work
service crashplan stop # OR systemctl stop crashplan
STEP 4 – The MAGIC which makes it work
The essentials are JNI/JNA and JTUX, without them CrashPlan won't work on your ARM device. Plus there's tidying up the mess CrashPlan has made of trying to install the Intel/AMD stuff.
cd /usr/local/crashplan mkdir ./bak # backup the i586 .so files mv *.so ./bak mv *.lic ./bak # backup the i586 JRE files mv ./jre ./jre-i586-bak # create a symbolic link for java 8 in crashplan directory ln -s /usr/lib/jvm/java-8-oracle/jre ./jre # create a symbolic link for JNI dispatcher # your “arm-linux-gnueabihf” may differ depending on your ARM architecture ln -s /usr/lib/arm-linux-gnueabihf/jni/libjnidispatch.so ./libjnidispatch.so
For JTUX I used the Arch Linux .so file, which works fine on my platform. You may want to patch and compile as described here, especially if your architecture is armel - see http://archlinuxarm.org/forum/viewtopic.php?f=31&t=5120 , and you'll need to patch JTUX as described.
Easy way for armhf - RPi / Odroid et al :
# Get the libjtux.so file (the one I used) wget http://dl.dropbox.com/u/6902100/archlinux/rpi-crashplan/arch_compiled/libjtux.so # OR wget http://www.jonrogers.co.uk/wp-content/uploads/2012/05/libjtux.so
(source - http://www.jonrogers.co.uk/2012/05/crashplan-on-the-raspberry-pi/ )
STEP 5 – Tell CrashPlan where JNA is
There's some CrashPlan config files we need to edit …
cd /usr/local/crashplan/bin # make a backup in case you fuck it up cp CrashPlanEngine CrashPlanEngine.bak vi CrashPlanEngine
You need to change :
FULL_CP="$TARGETDIR/lib/com.backup42.desktop.jar:$TARGETDIR/lang"
To
FULL_CP="/usr/share/java/jna.jar:$TARGETDIR/lib/com.backup42.desktop.jar:$TARGETDIR/lang"
(source - https://melgrubb.wordpress.com/2014/08/01/raspberry-pi-home-server-part-10-crashplan/ )
STEP 6 – Make the CrashPlan server available for remote access (ie headless)
cd /usr/local/crashplan/conf vi my.service.xml
You'll need to change this line :
<serviceHost>localhost</serviceHost>
to
<serviceHost>0.0.0.0</serviceHost>
STEP 7 – Start the CrashPlan server
service crashplan start # OR systemctl start crashplan
STEP 8 – Connect to the CrashPlan server from your laptop or desktop (ie "the client")
For simplicity I'm assuming a linux desktop or laptop (although the same is possible from a windows machine, just different file locations on windows). You need to download and install the CrashPlan application (AGAIN) on your laptop or desktop. Then modify this file locally :
vi /usr/local/crashplan/conf/ui.properties
Uncoment and change this line from :
#serviceHost=127.0.0.1
To
serviceHost=192.168.1.233
where 192.168.1.233 is the IP address of your ARM CrashPlan server.
NOW THEN, the above used to be enough, BUT it seems CrashPlan have added a new “feature” which took me ages to figure out and was preventing me connecting to my CrashPlan server. They've introduced a token file, which, if the client application (CrashPlanDesktop) doesn't have access to, then you've get an error in your server's service.log.0 file, complaining about the token being invalid. CrashPlan's own guide about headless server connection doesn't even mention this token, so I suspect it's a very new addition.
Fix by :
# backup your desktop or laptop's token cp /var/lib/crashplan/.ui_info /var/lib/crashplan/.ui_info.bak # copy your server's token to your desktop/laptop scp root@192.168.1.233:/var/lib/crashplan/.ui_info /var/lib/crashplan/.ui_info
Then run :
/usr/local/crashplan/bin/CrashPlanDesktop
If all went well, then you should be accessing your ARM device's CrashPlan server with the client application on your desktop or laptop.
STEP 9 – A bonus to speed things up
You can certainly dig around in the config file on your CrashPlan server my.service.xml and there's a lot of settings which can be adjusted to suit your needs. Some of these settings are available in the CrashPlan client app too. This one isn't, and hopefully will save you some time …
Rationale – there's really no point in compressing files which are already compressed.
Change the /usr/local/crashplan/my.service.xml file from :
<noCompressionPatterns>
<patternList>
<windows/>
<macintosh/>
<linux/>
To :
<noCompressionPatterns>
<patternList>
<pattern regex="(?i).*\.(?:ecc|par|par2|zz|zpaq|zoo|zip|zipx|yz1|xp3|xar|wim|war|uha|uca|uc|uc0|uc2|ucn|ur2|ue2|tar\.gz|gz|tgz|tar\.Z|tar\.bz2|tbz2|tar\.lzma|tlz|sit|sfx|sen|sea|sda|rk|rar|qda|pit|pim|pea|paq6|paq7|paq8|partimg|pak|lzx|lzh|lha|jar|ice|hki|ha|gca|ear|dmg|dgc|cpt|cpi|cfs|cab|bh|ba|b1|arj|arc|apk|alz|afa|ace|s7z|7z|Z|z|sfark|rz|lzo|lzma|lz|gz|F|bz2|mp3|mp2|aac|m4a|mp4|m4p|wma|flac|la|ape|jpg|jpeg|gif|png|iso|exe|bin|pdf|mkv|mov|avi|mpeg|mpg|m4v|m2v|qt|flv|ogv|ogg)"/>
<windows/>
<macintosh/>
<linux/>
It's also possible to switch off compression globally, but not sure I'd recommend that unless all your files are compressed …
Job done I think …
Enjoy
(PS - If anyone knows how to switch off CrashPlan automatic updates, please could you tell me ! )