A lot of exciting changes are happening, and at least one major disappointment. There’s a new Raspbian image out(https://www.raspberrypi.org/downloads/raspbian), and it brings a new desktop along with it (https://www.raspberrypi.org/blog/introducing-pixel). The Pixel desktop is a Pi-optimized LXDE variant, and it looks pretty much like what you’re used to if you’ve built a Pi since the beginning of the year. There are some notable changes, though.
Chromium Browser: This is the open-source version of Chrome, and while we’ve always had the ability to install it ourselves, it’s there by default now. Not only that, but it’s got some plug-ins preconfigured to make the web more Pi-friendly. In particular, it’ll force YouTube to send videos in a format that the Pi can decode more easily using hardware acceleration. That doesn’t really mean much to a server, but it’s a welcome upgrade.
Built-in VNC: That whole chapter I wrote about x11vnc? Yeah, you can forget that now. You now have a working remote desktop included in Raspbian out of the box. Just download the RealVNC Viewer and connect. It might be possible to use other viewers like UltraVNC, but it’ll take some configuration. The RealVNC viewer is small, portable (no need to install it), and works immediately. I’ve made the switch.
And now for the bad news. The folks at Code42 have been pushing updates to CrashPlan at an increasing rate, and every time CrashPlan updates itself, it breaks all of the patching and tweaking we had to do to get it running. At first, this was merely annoying. Now it’s become unmaintainable. I can’t trust my backup machine if it can be brought down at any time by a silent, compulsory update. I’m working on a new blog post about alternative approaches to using CrashPlan at home, and I’m hoping that the Pi can still be a part of that setup.
In the meantime, if you want to continue holding the Pi’s hand, and diving into the guts of CrashPlan roughly once a week, be my guest, but I won’t be putting any more time into maintaining the CrashPlan instructions unless I hear that Code42 has either started supporting ARM-based devices directly, or at least given us an alternative to stop the constant updates from undoing everything.
MelGrubb.ToBlog() 
Thanks again for this blog – it’s what finally convinced me to use a Pi for a general-purpose home server over a year ago, and I’m not looking back.
I share your disappointment at Crashplan’s recent breakage. It seems to come down to one binary library, libc42archive.so, which is compiled for X86 and proprietary to Code42, so there’s no ARM version (that I can find). Now it takes 3 libraries (the above, plus md5 and jtux) to run CP on the Pi.
As an interim, I rooted around on the CrashPlan site and grabbed a copy of 4.7 and reinstalled it in place of 4.8, and it’s running again. I tried some filesystem tricks to prevent the auto-updater from again bumping it to 4.8.
But of course this is not a long-term solution.
So I’ll be looking around and looking forward to what you and others find as an acceptable alternative to CrashPlan.
Bacula(.org) seems promising and has a long history, but looks like it could be complicated to setup.
One of the features I’ll miss most in Crashplan was that it would not store the same file twice, even if you have duplicates on the source. It saves a lot of space and bandwidth that way.
FWIW, I’m exploring using QEMU to emulate x86, then running CrashPlan under that. It’ll be slower, but speed isn’t the key factor in backup applications.
Will report on the outcome.
Please let us know if it worked out. Speed is not an issue in my case either, but crash plan not working on the pi is.
I was unsuccessful at getting CP to run using the free QEMU package. QEMU has both a full-system emulator (not enough memory for that on the Pi) and a user-space emulator. In the latter, I *was* able to get CP to launch and it seemed to run, but only for about 30 seconds. At first, the crashes were logging errors I could correct. Then, it ended up where it just hung after about 30 seconds, but not having opened any network listening sockets or do any filesystem access, so I could not communicate with it.
It’s just a Java process with a few external library calls, but debugging it further is beyond my knowledge and/or patience.
So, I’ve decided to change my backup scheme and utility. After looking at about a dozen free tools, I’ve settled on BackInTime (.org). Mainly because it is just a pretty face in front of good old rsync. It does not deduplicate files (so if you rename or move a directory, it gets copied to the repository again), but it does make efficient snapshot backups using hard links for files that haven’t changed, so the space waste is kept down.
It’s got more than one developer, I believe, and is still being maintained/developed, where many of the others have gone stale.
I also like that the backups are just files, so restores are possible without having BackInTime installed.
It can also backup to Amazon and other cloud services.