electronic.alchemy :: zfsbackup-go on SmartOS to BackBlaze B2
electronic.alchemy
where the past meets the future
smartos > zfsbackup-go

zfsbackup-go on SmartOS to BackBlaze B2

Created by hww3. Last updated by hww3, 6 years ago. Version #3.

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

Not categorized | RSS Feed | BackLinks

comments powered by Disqus