I like CrashPlan. They support a wider range of operating systems than some of their competitors, they have a simple pricing model, unlimited storage & retention, and a nice local, mobile, and web interfaces. I’ve been a customer for a few years now, and recently have switched a few of my clients’ businesses over to them, too.
What I don’t like is that they don’t seem to support Linux very well, which is typical of companies when their installed base is mostly Windows & Mac. Most notably, their install instructions are sparse and they don’t tell you what packages you need to have installed, which is important because cloud VMs and whatnot are usually “minimal” installations. I’ve attempted to open a support case, but they suggested running a “headless” client, which is both unsupported and a huge pain. And then they closed the support case, because it’s unsupported! DOH.
So here’s how I get CrashPlan installed on Linux in case it helps others, and maybe Code42 themselves.
- As of this writing the CrashPlan software is version 3.7.0.
- I am doing this on Red Hat Enterprise Linux, CentOS, and Oracle Enterprise Linux 5, 6, and 7 servers.
- These servers have outbound access to the Internet.
- I am using a Windows 7 desktop.
- This document assumes you’ve done some things with Linux before.
- This document assumes you’re logging in as yourself and then using sudo to run things as root.
- Your mileage may vary, and my ability to help you is limited. I don’t work for Code42. That said, if you can improve this document please let me know how.
1. Your Linux server has to have a few packages on it to enable basic X Windows support for the CrashPlan GUI. Most cloud servers are built with a minimal installation and don’t have these. On Enterprise Linux variants you can issue the command:
sudo yum install xauth xterm wget xorg-x11-fonts-Type1 xorg-x11-font-utils libXfont
This will get you xterm, so you can test the setup, xauth which is part of the X Windows authentication setup, and the fonts the client will need. It also grabs wget, which the CrashPlan installer will use to retrieve a copy of the Java Runtime Environment.
2. You need to forward X Windows (X11) graphics to your desktop. To do this you need what’s called an X Server, and you need an SSH client that can forward X11 packets. Given that you did #1 already you probably have SSH. I’m on Windows, so I use:
Xming — http://sourceforge.net/projects/xming/ — the X Server you need
PuTTY — http://www.chiark.greenend.org.uk/~sgtatham/putty/ — a free SSH client
I actually use Van Dyke’s SecureCRT — http://www.vandyke.com/products/securecrt/ — but it’s a commercial product. IMO, totally worth it if you spend a lot of time logged into UNIX hosts, though. Both it and PuTTY can forward X11.
Install these things. Run Xming (not Xlaunch, etc.) and your SSH client of choice. Xming may trigger a firewalling prompt under Windows. The X Windows data will be coming across the SSH connection you’re about to establish, so you shouldn’t need to open anything up.
3. Set up a new SSH connection, or edit an existing one, and tell it to Enable X11 Forwarding. Here’s where the X11 option is in PuTTY:
Open that connection.
4. Run ‘xterm’:
You should see:
If you get this error on the console:
xterm: Xt error: Can't open display: localhost:10.0
Check to make sure Xming is running. If you get:
xterm: Xt error: Can't open display: %s xterm: DISPLAY is not set
Forwarding isn’t working when you logged in. Check your settings, and check to make sure that xauth and xterm got installed correctly. If you’re ssh’ing from a command line, like on a Mac or through a second server you might need:
ssh -Y hostname
5. Close xterm – you can either type ‘exit’ like in a normal shell or just close the window like a normal window. That was just to check to make sure forwarding was working.
6. Put the CrashPlan installer on the Linux server. My favorite way to do this is to copy the direct download link from CrashPlan and paste it into wget, but you can use sftp, scp, Zmodem, whatever.
Then expand it:
gtar xlzf CrashPlanPRO_3.7.0_Linux.tgz cd CrashPlanPRO-install/
7. Run the installer as root. The CrashPlan service needs to run as root if you want it to back up the whole system, and the installer will want to put startup files in the right spots so CrashPlan starts after a reboot. This is a good idea.
8. Answer questions, read the EULA. You can get out of the EULA by hitting ‘q’. I let it put everything in the default locations.
9. Let it start the CrashPlanDesktop app. In a few moments you should see the GUI pop up. Log in, do your thing. You will likely have to adjust what it’s backing up if you want it to get system files and such. Be careful, though, because it’ll back up things that change, and a lot of system files change a lot. You might want to consider lowering the backup frequency in that case.
10. If the CrashPlan GUI didn’t start you can try running it manually:
If you get errors about permissions check your forwarding again (run xterm). If you’re trying to run it with sudo you might be getting permission errors. X Windows has some authentication in it so people can’t just pop windows open on your desktop. You can give root permission, though, by copying your .Xauthority file to root’s home directory:
cd ~; sudo cp .Xauthority /root/.Xauthority
You shouldn’t need this, though. The CrashPlan client will work when run as your user.
11. If you don’t want all the users on your server to be able to run CrashPlan you should set the CrashPlan client itself to require a password to run. This is the easiest way to handle this, but it requires that people who need to do a restore have the password to the account that it was set up under. Thus, in a multi-admin environment you might want to create a shared user to log in as.
Another way to do this is to create an archive password which is shared. You won’t ever be able to remove the archive password once you do that, though you can change it.
You might be tempted to just change the permissions on /usr/local/crashplan/bin/ so only root can get there, but remember that anybody can copy the GUI to the server and run it.
12. Make sure you have a firewall protecting incoming connections, as the CrashPlan backup engine listens on tcp/4243. You don’t want that open to the world.
13. I actually create a separate /usr/local/crashplan filesystem before I install. CrashPlan keeps logs and file caches there and they get big sometimes, and this keeps them separate from everything else.
Good luck! If you see an error here or have a suggestion let me know in the comments. Thank you.
 I’m not kidding. SecureCRT supports Zmodem, and I install lrzsz on all my servers so I can just type ‘rz’ to send a file to the server and ‘sz’ to send one back. Encrypted, fast, easy.
Comments on this entry are closed.
CrashPlan’s security is pretty terrible. Look at http://web.archive.org/web/20121011025807/http://blog.androgynoid.com/2012/10/crashplans-horrible-password-reset.html and consider whether you still trust them with your data. I’d recommend tarsnap instead. Open source, paranoid security, etc.
I’m reading through that right now. It is from 2012 but it’ll be easy enough to run through most of that and see what’s been fixed.
Tarsnap — um, they charge in picodollars per byte/month. Really guys?
I’ve had great success with Duplicity. It’s CLI-based, and not the most user-friendly thing in the world, but I’ve been throwing regular PGP-encrypted backups straight to S3 for a couple of months now with zero issues. It’s straightforward, and you’re just paying for S3 directly instead of dealing with a markup imposed by a third-party company. Even better, you can configure your S3 bucket to slough off all backups older than a certain date to Glacier storage, so your costs drop from roughly $0.03/gb to $0.01/gb (as of 01/2015). If you decide to check out duplicity, feel free to steal from my ghetto-fabulous, ‘does it all’ shell script: