Testing zxfer(8)

Published: 2022-03-02

Note: Most of this post was written back in december, shortly after I wrote the previous one. but I never got around to actually publish it. This also cut short my experimentations, as I use the result of this post since december.

After thinking about different ZFS replication tools in the last post, I decided to try zxfer(8) first, as it seems to align best with my requirements and preferences.

First, I install it on my laptop:

$ doas pkg install zxfer
Password:
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        zxfer: 1.1.7

Number of packages to be installed: 1

35 KiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching zxfer-1.1.7.pkg: 100%   35 KiB  35.4kB/s    00:01    
Checking integrity... done (0 conflicting)
[1/1] Installing zxfer-1.1.7...
[1/1] Extracting zxfer-1.1.7: 100%

To prevent zxfer(8) from needing root privileges, delegate the user who will run it the rights to create snapshots:

$ doas zfs allow -u flo compression,create,mount,mountpoint,receive,snapshot tank/backup
Password:
$ zfs allow tank/backup
---- Permissions on tank/backup --------------------------------------
Local+Descendent permissions:
        user flo compression,create,mount,mountpoint,receive,snapshot

Since the datasets must be mounted by this user, the vfs.usermount sysctl must be set to 1, and the tank/backup dataset must be owned by this user:

$ doas sysctl vfs.usermount=1
Password:
vfs.usermount: 0 -> 1
$ doas chown -R flo:flo /backup/resurgam
Password:

To make this sysctl persistent, add it to sysctl.conf(5):

$ echo vfs.usermount=1 | doas tee -a /etc/sysctl.conf

On the remote side, similar adjustments are necessary, since root logins are forbidden by the sshd config and changing that is definitly not a good idea:

resurgam$ doas zfs allow -u flo send,snapshot zroot/data
Password:

Since all the snapshots from the zroot/data dataset should be fetched, it needs to be created first:

$ zfs create tank/backup/resurgam/data

Now, fetch the snapshots from the server:

$ zxfer -FkPUv -I canmount,exec -O resurgam -R zroot/data tank/backup/resurgam

The options are as follows:

-F: Force a rollback of the destination to the latest snapshot.
-k: Backup the original filesystem property settings to /backup/resurgam/.zxfer_backup_info.data
-P: Transfer the properties from the source to the destination datasets. This needs some exceptions, see below at the -I option.
-U: Skip properties unsupported on the destination.
-v: Be verbose. I will probably remove this for “production” use, as it creates a lot of output.
-I canmount,exec: Ignore the canmount and exec properties from the source dataset. I have the exec property disabled on the data datasets on my server, which conflicts with the local settings. The same goes for the canmount property.
-O resurgam: Pull from the “resurgam” host. Take care that port forwarding setup prevents multiple independent SSH connections to the same host.
-R: Recursively transfer the snapshots.

This produces a lot of output, but in the end I have all the snapshots from my server in my local dataset. It therefore looks like I found a working solution on the first try!

To weed out the shorter term snapshots, add the -d flag. To not remove the long-term backups, also add the -g option specifying a number of days. Snapshots older than this are kept. I decided to use 365 days, resulting in this “script”:

zxfer -dFkPUv -g 365 -I canmount,exec -O resurgam1 -R zroot/data tank/backup/resurgam

If I had already fixed by storage server, I would put this into a cron-job on it. But currently the pen drive containing the root filesystem is broken and I have not yet ordered a replacement, so for now I use this from a shell script on my laptop.