It’s taken quite a while, but I have replaced my home server’s OS with SmartOS. (It was previously running Windows with Hyper-V. Look for a future blog post about the migration in general.) With the previous layout, I had a single Linux guest called “nas” that was my file server, but did triple-duty running Plex and the CrashPlan client as well. After migrating most of my other Hyper-V guests to OS zones where possible, it was time to tackle getting a CrashPlan zone going. Unfortunately, Code42 retired Solaris as a supported platform a while back. However, since it’s “just Java”, I figured the Linux package might work in an LX-brand zone. Turns out, it works quite well–with one minor caveat.

(I won’t rehash what an LX zone is; instead I will point you towards Bryan Cantrill’s excellent talk, The Dream is Alive! Running Linux containers on an illumos kernel.)

Why?

I use CrashPlan as a local backup target for various clients on my home network. Some of these clients (like my desktop and laptop) backup to both this internal host and to the CrashPlan service, and some only backup to the internal host, depending on how important I deem their data. For months I did not have this local backup target available, and it was time to change that.

Zone Creation

So, first I needed an LX zone. Using imgadm avail I found a few different images that I could potentially use. I decided to go for an Ubuntu zone:

root@vm ~ $ imgadm avail | grep lx-ubuntu
818cc79e-ceb3-11e4-99ee-7bc8c674e754  lx-ubuntu-14.04         20150320    other    2015-03-20T03:45:09Z
430da066-e3a7-11e4-9657-332a2dbdf565  lx-ubuntu-14.04         20150415    other    2015-04-15T19:40:25Z
a21a64a0-0809-11e5-a64f-ff80e8e8086f  lx-ubuntu-14.04         20150601    other    2015-06-01T02:55:17Z

I simply chose the most recently-released lx-ubuntu image I could find at the time and constructed the following zone configuration file:

{
  "alias": "crashplan",
  "hostname": "crashplan",
  "brand": "lx",
  "kernel_version": "3.13.0",
  "quota": 10,
  "max_physical_memory": 2048,
  "image_uuid": "a21a64a0-0809-11e5-a64f-ff80e8e8086f",
  "resolvers": ["192.168.2.1"],
  "nics": [
    {
      "nic_tag": "admin",
      "ip": "192.168.2.20",
      "netmask": "255.255.255.0",
      "gateway": "192.168.2.1",
      "primary": true
    }
  ],
  "filesystems": [
    {
      "type": "lofs",
      "source": "zones/crashplan",
      "target": "/opt/crashplan"
    }
  ]
}

Note the filesystems section. Here I am telling vmadm(1M) that I want to mount the zones/crashplan dataset into the zone at /opt/crashplan. This will become Crashplan’s default backup archive location, where all backup data from other computers will be stored. Before creating the zone, I had to create a new ZFS filesystem called “zones/crashplan”, like so:

root@vm ~ $ zfs create zones/crashplan
root@vm ~ $ zfs set compression=off dedup=off zones/crashplan
root@vm ~ $ zfs get compression,dedup zones/crashplan
NAME    	PROPERTY	VALUE		SOURCE
zones/crashplan	compression	off		local
zones/crashplan	dedup		off		local

root@vm ~ $ zfs list zones/crashplan
NAME		USED	AVAIL	REFER	MOUNTPOINT
zones/crashplan	19K	855G	19K	/zones/crashplan

Here, I’ve created the ZFS dataset and turned off compression and deduplication. Since CrashPlan does its own compression (I think) and deduplication (for sure), I didn’t see a need to make ZFS try to do the same things over again.

To make sure I have all syntax right (because that’s rarely a thing on the first shot), I typically check the JSON file with vmadm validate and then create the zone if it is valid:

root@vm /opt/vmdefs $ vmadm validate create -f crashplan_lx.json 
VALID 'create' payload for lx brand VMs.
root@vm /opt/vmdefs $ vmadm create -f crashplan_lx.json 
Successfully created VM f5b988e9-260b-4103-8bab-441c8e0df0fe
root@vm /opt/vmdefs $ vmadm list | grep crashplan
f5b988e9-260b-4103-8bab-441c8e0df0fe  LX    2048     running           crashplan

CrashPlan Installation

At this point, I could log in to the zone and treat it just like a normal Ubuntu host, meaning that everything from here on is the same as when I installed CrashPlan on the previous, real Linux guest. After updating the zone, I downloaded the Linux CrashPlan client and copied it over, then installed the app as per the documentation (starting at “Extract the TGZ…"). Since this install was going to be headless, I then switched over to the headless usage guide and followed the instructions there.

root@crashplan:~# tar xzf CrashPlan_4.4.1_Linux.tgz
root@crashplan:~# cd crashplan-install/
root@crashplan:~/crashplan-install# ./install.sh 
[...]
root@crashplan:~/crashplan-install# service crashplan status
CrashPlan Engine (pid 75632) is running.

I used my laptop’s CrashPlan client to configure the host (as per the headless guide). Once I was done configuring and had restored “normal operation”, I enabled my new host as a backup target on my laptop and watched it merrily start backing up!

Caveat

I was so happy about having CrashPlan working under an LX zone that I tweeted about it…and as sometimes happens, I was informed of a potential issue:

The bug relates to this troubleshooting guide and seems to be specific to using the CrashPlan client to watch for changes on the local filesystem and sync them in real-time to a remote backup target. So far I have not been bitten by this particular issue and, since I am not backing up my local backup server to another backup server (wat) I don’t think I will run into it any time soon. But if this is something you want to do, you might want to watch that Github issue.

Conclusion

Since standing up the zone I’ve pointed my desktop and laptop at it, and they’ve been backing up perfectly fine ever since.

root@vm ~ $ zfs list zones/crashplan
NAME		USED	AVAIL	REFER	MOUNTPOINT
zones/crashplan	230G	763G	230G	/zones/crashplan

And here’s one of my favorite parts: instead of wasting an entire 2+GB of memory had I built this as a KVM guest, the zone is using less than a quarter of that!

root@vm ~ $ zonememstat -az f5b988e9-260b-4103-8bab-441c8e0df0fe
                                 ZONE         ALIAS  RSS(MB)  CAP(MB)    NOVER  POUT(MB)
 f5b988e9-260b-4103-8bab-441c8e0df0fe     crashplan      352     2048        0         0

I’ve been very happy with SmartOS in general and the flexibility of OS vs. LX vs. KVM zones in particular. If you’re looking for a nice hypervisor-type OS, SmartOS deserves some serious consideration.