Installing ZFS on Debian Buster

This has been an interesting one to look at recently – and how wrong was I when I thought that installing ZFS would be as simple as installing the apt package. Turns out I was slightly ahead of the curve…?

Background to this – I have been running FreeNAS as my home NAS for a number of years now. Protecting the data on that system used to be down to Crashplan. When they announced they were closing the CrashPlan Home plan, I was grandfathered into the CrashPlan Small Business plan for around a year at a generous discount until that ended in April. I had already started looking at solutions a while back, but still firming up on my options. This blog is going to focus getting ZFS running on a Raspberry Pi, to determine if ZFS snapshot replication to a remote system would be the answer. I have also been trying other options. Ultimately, between two solutions it will involve placing a device in another families home and shipping my backups to that device for off-site protection.

Idea here is that I want to use an SBC (Raspberry Pi or fruity variant) to replicate ZFS snapshots to for offsite backups. These devices are not very powerful, however I would not be accessing the data on these regularly – rather using it as an archival point to re-ingest ZFS datasets should my main FreeNAS run up against a wall.

There is plenty of other discussions and opinions on backup strategies. I am fully aware and of them, but will not be divulging in those with this post – this is more the technical capability / configuration to make this work.

First of all trying this on a brand new Raspberry Pi 4. This awesome little device has just been revamped and has much better performance vs it’s predecessors and also a choice of RAM sizes. The Pi 4 I have at the moment is packing 4GB of RAM. Typically a good choice for ZFS is to be above 2GB for expected home performance, but I can touch on how it’s utilizing that later. Find out more about these on Raspberrypi.org

Raspberry Pi 4 Model B

Of course, being a brand new Pi to the market, Raspbian Buster is currently the only distribution offering full hardware support. I might reconsider this as other distributions start to catch up and offer support, however my choices are limited right now – hence the comment around perhaps being ahead of the curve.

So, the Raspberry Pi 4, given it has a bus connected 1Gbps network adapter, and USB 3.0 connectivity looks like it will be a nice fit to send ZFS snapshots to for off-site protection. Attach a USB 3.0 HDD (I’m using a Seagate 5TB portable drive) and configure for ZFS.

Seagate 5TB Drive

I’m not going to go into installing Raspbian on the Pi, there’s plenty of resources around that elsewhere. Let’s assume you have Buster online, updated and ready to install ZFS.

First of all, you are going to want to add the Debian contrib repository, as the Raspbian repo’s currently do not have all of the ZFS apt packages available. **Update**: I’ve removed the need to grab the keys and add as it’s a debian source, and fixed echoing the line out to sources.list. This worked for me as of May 2020.

If you do need to add keys, try the below (big thanks to Colin Ng for helping here!):

Then we are ready to install ZFS. This will take a while, as it compiles the ZFS support for your installed Linux kernel.

Word of note here. The installer does mention and warn about you installing ZFS on a 32-bit system and it not being recommended. Being SoC is 64-bit capable, I did look for a 64-bit OS but did not turn up much. I proceeded knowing that this could cause issues, but will re-evaluate once a 64-bit distribution comes available for the Pi 4.

If the install happens to fail – it could be you are missing the kernel headers. Try installing them first then run the previous command again. (Again thanks to Colin Ng for the clarification here!)

Once complete, either restart your Pi, or you can load the ZFS module:

Now we should ready to create our ZFS filesystem. If you got any errors in the previous steps, try rebooting and running the commands again.

You will need to identify the disk(s) you want to create your ZFS pool on. Check for disks using:

Once you know which disk to you, you can create your zpool:

For my setup I did:

That’s it! You can view the pool by doing:

Now you can look at configuring your ZFS snapshot replication and testing. More to come on that front.

General around memory usage – I have found the Pi sits around 750Mb of RAM used, and a load average of 3.30 during ZFS receive operations. Seems pretty reasonable – I am doing lz4 compression on transmission via SSH, and the datasets also have lz4 compression enabled.

Throughput wise, seems that I am getting just over 60Mb/s through the network adapter. I am guessing the bottleneck will be the HDD on the Pi. Pretty reasonable given the cost and power consumption of the Pi!

If you do see slow speeds, make sure your power supply / USB cable can provide enough juice to the Pi. I started off with a USB cable plugged into a USB port on a laptop and it was not happy. I kept getting throttled warnings in the /var/log/messages as it was under-voltage. Once I swapped the Pi onto the power adapter for my Nintendo Switch those warnings went away and the performance shot up!

Will post again with more specifics around getting FreeNAS to replicate to the ZFS pool on the Pi soon. Stay tuned for that!

6 thoughts on “Installing ZFS on Debian Buster

  1. Thanks for your article! Since the default Raspbian Buster image does not include the Kernel Headers, then installing zfs-dkms will likely fail for most people with a message like so:


    Building for 4.19.58+, 4.19.58-v7+ and 4.19.58-v7l+
    Module build for kernel 4.19.58+ was skipped since the
    kernel headers for this kernel does not seem to be installed.
    Module build for kernel 4.19.58-v7+ was skipped since the
    kernel headers for this kernel does not seem to be installed.
    Module build for kernel 4.19.58-v7l+ was skipped since the
    kernel headers for this kernel does not seem to be installed.

    Before the zfs-dkms install, run:


    apt-get install -y raspberrypi-kernel-headers

  2. Thank you for writing this. However, this doesn’t work.

    gpg –keyserver pgpkeys.mit.edu –recv-key 04EE7237B7D453EC
    gpg: keybox ‘/home/pi/.gnupg/pubring.kbx’ created

    gpg: keyserver receive failed: No keyserver available

    Any idea what happened or how to fix?

    I have extensive FreeNAS experience, and wanting to make my Pi backup to the FreeNAS/TrueNAS. 😀

    • Sorry for the late reply! 🙁 There was a lot of public key infrastructure problems around the time I posted / created this. I suspect they may be resolved now.

  3. Hi, sorry just saw this now. My old notes (working as of today, 2020-05-01) say this:

    Accept these signing keys:

    sudo gpg --keyserver keyserver.ubuntu.com --recv-key 04EE7237B7D453EC
    sudo gpg -a --export 04EE7237B7D453EC | sudo apt-key add

    Since pgpkeys.mit.edu was down, I substituted keyserver.ubuntu.com that I got from the list of [PGP: Public Key Servers](https://www.rossde.com/PGP/pgp_keyserv.html#pubserv).

    content_copy
    sudo apt update

    • Thanks for commenting! I’ve just updated that section. On a clean buster install I was able to just add the contrib repo without keys and install from it. Note was not a RPi as currently testing on a SOC / Dell Wyse client.

  4. Oh, and for first-time Kernel hackers, we have to install the [Raspbian Kernel Headers|https://www.raspberrypi.org/documentation/linux/kernel/headers.md]:

    sudo apt-get install raspberrypi-kernel-headers

Leave a Reply

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