Just a quick query. I tested sending from one server to another, both with zfs backed storage and expected to see a zfs send behind the scenes, but it seems to be using rsync, which I guess is a lot slower than zfs send.
I thought from reading the original thread the idea was to use the zfs send or btrfs send if you have that type of storage backing your system as its more efficient? I know with syncoid it will send in a second if there are not many changes between storage dataset and this uses zfs send.
So the problem is that due to how LXD works, there’s nothing preventing you from starting and messing with the container on the target, effectively breaking any attempt at doing send/receive on top of that.
The only way we could have gotten send/receive to work is by deleting and re-sending the entire thing every time, so not so incremental.
With rsync, we can delete and re-create any snapshot and container data which appears to have differed on disk, without requiring the parent datasets to actually be identical.
Syncoid and similar ZFS backup solutions don’t have that problem because it’s assumed that the target server is effectively read-only and only used to receive dataset deltas from the source. This isn’t something we can rely on in our case.
There’s still nothing wrong with you using syncoid or similar solutions to backup the ZFS storage pool that LXD uses, then use lxd import in a disaster recovery situation to re-import those containers and snapshots.