AutoCreated (and/or subsequently replicated) destination datasets do not retain properties of their sources

[jimklimov]

As seen in quick check below, a backup of the root dataset does not carry over custom properties for its role as a boot environment (these libbe props in particular tie together linked local zone roots, for example -- so for the purposes of eventual systems recovery, lack of such attributes is a loss of useful data):

root@jimoi:/root# zfs get all backup-adata/snapshots/nvpool/ROOT/hipster_2020.04 | grep be
backup-adata/snapshots/nvpool/ROOT/hipster_2020.04  mlslabel                    none                                                               default

root@jimoi:/root# zfs get all nvpool/ROOT/hipster_2020.04 | grep be
nvpool/ROOT/hipster_2020.04  mlslabel                      none                                                               default
nvpool/ROOT/hipster_2020.04  org.opensolaris.libbe:policy  static                                                             local
nvpool/ROOT/hipster_2020.04  org.opensolaris.libbe:uuid    e971bc18-f823-e239-85b7-b58a1c79b271                               local

Normally such properties are received on destination if zfs send -R were used for replication (#438) or zfs send -p otherwise (if supported by both sides of the dialog - works in Solaris 10u10, probably earlier too). It is possible to do same manually as in e.g. (shameless plug) https://github.com/jimklimov/illumos-splitroot-scripts/blob/master/bin/beadm-clone.sh#L50 (UPDATE: or shortened example in comment below)

[jimklimov]

One self-reminder about replication of properties: while on backups it may be reasonable to just "receive" them, in case of similar manual replication activity onto another active pool (e.g. migration of live data to different storage to take over) be careful to replicate the properties of znapzend backup plans into new originals manually so they are deemed local there (and so recognized as backup plans in their new home), AND tell your zfs recv to not overwrite them with values from replication stream which carries over customized parameters, like this:

# zfs send -R nvpool/zones@20200821-01-running | mbuffer -m 8g | \
   zfs recv -vudF  -x org.znapzend:dst_0 -x org.znapzend:dst_0_plan \
    -x org.znapzend:mbuffer_size -x org.znapzend:mbuffer -x org.znapzend:src_plan -x org.znapzend:tsformat \
    -x org.znapzend:recursive -x org.znapzend:enabled -x org.znapzend:pre_znap_cmd \
    -x org.znapzend:post_znap_cmd newnvpool

This can be generated by the likes of:

### Save the source custom properties
:; zfs get -H -r -s local,received all nvpool > ~/zpool-local-props-20200820-nvpool.txt
### Create new backupSet roots in "newnvpool" with same settings as those in old "nvpool"
### No problem creating (-p) over an existing dataset so no filtering below
:; grep -v @ ~/zpool-local-props-20200820-nvpool.txt | grep org.znapzend | while read D K V S ; do zfs create -p new"$D" ; done
### Replicate the settings
:; grep -v @ ~/zpool-local-props-20200820-nvpool.txt | grep org.znapzend | while read D K V S ; do zfs set "$K=$V" new"$D" & done

### Later during send-receive, the list of properties to exclude for a backupSet setup can be generated with e.g.:
:; zfs get -s local all newnvpool/zones | grep org.znapzend | awk '{print "-x "$2}' | tr '\n' ' '
### ...and substituted or just copy-pasted into `zfs recv` command line

CAVEAT EMPTOR: Such pre-created backupSet root datasets can be a problem if an original one sent via replication stream is a clone of something - it cannot then be received as an incremental stream. In such case (or any case?) replicate first, set local properties on new copy afterwards.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.