Syncoid - failed to send because child dataset with syncoid:no-sync=true has no snapshots

[luispabon]

I have the following set of datasets for libvirt VMs:

zroot/vms                          175G   288G   168K  none
zroot/vms/etc                     3.31M   288G   756K  /etc/libvirt
zroot/vms/storage-pool             170G   288G   147G  /var/lib/libvirt
zroot/vms/storage-pool-ephemeral  4.83G   288G  4.83G  /var/lib/libvirt-ephemeral

The zroot/vms/storage-pool-ephemeral is where I place VMs to try out and I don't want them to be snapshotted or backed up. So:

• It is excluded from sanoid
• It's marked with syncoid:no-sync=true

zfs get syncoid:no-sync zroot/vms/storage-pool-ephemeral

NAME                              PROPERTY         VALUE            SOURCE
zroot/vms/storage-pool-ephemeral  syncoid:no-sync  true             local

When I try to send the zroot/vms to my remote backup server I get the following:

~ syncoid --sendoptions="Rw" --no-sync-snap "zroot/vms" "vault:backups/luis-fw16/zroot/vms" 

NEWEST SNAPSHOT: autosnap_2024-09-13_08:18:20_daily
INFO: Sending oldest full snapshot zroot/vms@autosnap_2024-08-20_08:31:34_daily (~ UNKNOWN) to new target filesystem:
cannot send zroot/vms@autosnap_2024-08-20_08:31:34_daily recursively: snapshot zroot/vms/storage-pool-ephemeral@autosnap_2024-08-20_08:31:34_daily does not exist
warning: cannot send 'zroot/vms@autosnap_2024-08-20_08:31:34_daily': backup failed
0.00  B 0:00:00 [0.00  B/s] [<=>                                                                                                                            ]
cannot receive: failed to read from stream
CRITICAL ERROR:  zfs send -R -w  'zroot/vms'@'autosnap_2024-08-20_08:31:34_daily' | pv -p -t -e -r -b -s 0 | lzop  | mbuffer  -q -s 128k -m 16M | ssh      -S /tmp/syncoid-vault-1726226018-5562 vault ' mbuffer  -q -s 128k -m 16M | lzop -dfc | sudo zfs receive  -s -F '"'"'backups/luis-fw16/zroot/vms'"'"'' failed: 256 at /usr/sbin/syncoid line 549.

Seems counter intuitive that the dataset is explicitly excluded from sync's on syncoid yet syncoid expects datasets to be there. Perhaps I'm doing something wrong?

[phreaker0]

@luispabon yes you are doing something wrong :-) With the zfs send "-R" option you instructed zfs to do the recursive replication instead of syncoid. So all excludes which syncoid would handle have no effect:

       -R, --replicate
           Generate a replication stream package, which will replicate the specified file system, and all descendent file systems, up to the named snapshot.  When received, all properties, snap‐
           shots, descendent file systems, and clones are preserved.

           If the -i or -I flags are used in conjunction with the -R flag, an incremental replication stream is generated.  The current values of properties, and current snapshot and file system
           names are set when the stream is received.  If the -F flag is specified when this stream is received, snapshots and file systems that do not exist on the sending side are destroyed.
           If the -R flag is used to send encrypted datasets, then -w must also be specified.

You can use they "-X" option for zfs send to exclude datasets in an -R stream:

       -X, --exclude dataset[,dataset]…
           With -R, -X specifies a set of datasets (and, hence, their descendants), to be excluded from the send stream.  The root dataset may not be excluded.  -X a -X b is equivalent to -X
           a,b.

[luispabon]

Thank you @phreaker0. How can I specify that as syncoid send options though? The following upsets syncoid:

~ syncoid --sendoptions="RwX zroot/vms/storage-pool-ephemeral" --no-sync-snap "zroot/vms" "vault:backups/luis-fw16/zroot/vms"

invalid send options! at /usr/sbin/syncoid line 38.
Usage:
[ ... ]

[phreaker0]

@luispabon seems there is missing support for X with argument, you can temporarily patch syncoid to support it right away:

sanoid/syncoid

Line 2178 in 826d4d1

if ($char eq 'o' || $char eq 'x') {

replace that line with "if ($char eq 'o' || $char eq 'x' || $char eq 'X') { "

[luispabon]

Cheers. Looks like there's already a PR open for it:

#934