I have a large collection of filesystems and their snapshots that are backups of various other machines on zpool-current. These backups have been “defanged” by locally with recv -u -o mountpoint=none -o canmount=noauto. From what I have been able to find out, the received values are stored internally and opaquely for potential use with send
-b, --backup
Sends only received property values whether or not they are
overridden by local settings, but only if the dataset has ever been
received. Use this option when you want zfs receive to restore
received properties backed up on the sent dataset and to avoid
sending local settings that may have nothing to do with the source
dataset, but only with how the data is backed up.
I am creating zpool-new as RAIDZ1 so I don’t think I can magically move from a mirror to a RAIDZ1 configuration without a send-recv involved.
As I am not entirely sure how the magic of these hidden values work, is there a hidden pitfall in
zfs send -R -b zpool-current@final_snapshot \
| zfs recv -d -s -u -o mountpoint=none -o canmount=noauto zpool-new
Edit: Generally concerned about property loss. I’m now aware of and have resolved having too much metadata from the size of the filesystem/snapshot tree and having to chunk it up.