http://bill.welliver.org/atom/smartos/zfsbackup-go electronic.alchemy :: zfsbackup-go on SmartOS to BackBlaze B2 2026-05-01T04:41:09-04:00 Public.Syndication.ATOM (Pike v8.0 release 702) http://bill.welliver.org/favicon.ico http://bill.welliver.org/static/images/alchemy.gif zfsbackup-go is a utility that can be used to backup ZFS snapshots to cloud storage such as Google, Amazon or B2. This is a handy way to get offsite backups if you're already using ZFS snapshots to back up your data. I'm using zfsbackup-go to back up my existing SmartOS(illumos) ZFS snapshots offsite to BackBlaze B2. There were a few little tweaks that needed to be made to get things built and working on SmartOS; the B2 parts are not SmartOS specific and are mostly down to less than stellar documentation. Building zfsbackup-go on SmartOS Build the utility on a standard native zone with pkgsrc-trunk. The resulting binary can be copied to the GZ later, if desired.  pkgin in go113  ln -s /opt/local/bin/go113 /opt/local/bin/go   GOPATH=/root/go  export GOPATH go get https://github.com/someone1/zfsbackup-go I had a minor compilation problem with one or two of the dependencies, but it was easy to fix:  Add solaris to the list of build platforms in:  $GOPATH/go/pkg/mod/github.com/mattn/go-ieproxy@v0.0.0-20190610004146-91bb50d98149/ieproxy_unix.go  and  $GOPATH/go/src/github.com/Azure/azure-storage-blob-go/azblob/zc_mmf_unix.go  Additionally, in zc_mmf_unix.go, change the import of "syscall" to "golang.org/x/sys/unix" and change all the syscall references to unix. SSL Trust Store  Also, (and I suspect this affects most of the external backup providers) the go SSL implementation has hard coded locations for trust store certificates, and if the trust store can't be found, connections will silently hang without any errors. On SmartOS, you can fix this by running the following:   pkgin in mozilla-rootcerts  ln -s /opt/local/etc/openssl/ca-certificates.crt \ /etc/ssl/certs/ca-certificates.crt  BackBlaze B2  You'll need to set two environment variables containing your B2 account and key information. There's surprisingly little information about what these values are, so after extensive trial and error, here's where they seem to come from:  B2_ACCOUNT_ID: this is the keyID value displayed when you create a new application key in the B2 admin interface. You can see this listed with each application key later.  B2_ACCOUNT_KEY: this is the applicationKey value displayed when you create a new application key in the B2 interface. This value is only displayed once and should be saved for use later.  Usage The documentation for this tool isn't the best, I'm sure there are better ways to do this. However, I'm mostly interested in sending a full backup offsite.   This assumes you're using B2, that you've got a bucket created and an application key generated that has access to the desired bucket. I'm also encrypting my backups for good measure; for this you'll need a PGP keyring with a keypair. There are lots of discussions of this elsewhere, so I leave that as an exercise to the reader.  Here's the command I'm using (assuming the snapshot already exists):  B2_ACCOUNT_ID=myKeyID \  B2_ACCOUNT_KEY=myApplicationKey \  /opt/zfsbackup-go send --full -R \ --encryptTo myPGPKey@myDomain \      --signFrom myPGPKey@myDomain \ --publicKeyRingPath /zones/images/zfsbackup.pub \      --secretKeyRingPath /zones/images/zfsbackup.priv --logLevel debug \      --workingDirectory /zones/images/.zfsbackup \      zones b2://hostA-backup-2019/zones