It can be helpful to remember that while less efficient, for scenarios where ssh as root is a no-go you can ship snapshot syncs (including incremental ones) as files:
zfs send [...] tank > tank.zfssnap
cat tank.zfssnap | zfs recv [...] bankIt can be helpful to remember that while less efficient, for scenarios where ssh as root is a no-go you can ship snapshot syncs (including incremental ones) as files:
zfs send [...] tank > tank.zfssnap
cat tank.zfssnap | zfs recv [...] bankThis capability can also be extremely helpful for bootstrapping a big pool sync from a site with mediocre WAN (very common in many places, particularly when it comes to upload vs download). Plenty of individuals or orgs may be characterized by having quite a sizable amount of data accumulated by this point, but they're not generating new data at a prodigious clip. So if you can get the initial replication done, ongoing syncing from there can be possible over a fairly narrow pipe.
Latency might not be quite the best, but sometimes the greatest bandwidth to be had is a big fat drive or set of them in the trunk of a car :)
Computer Networks, 3rd ed., p. 83. (paraphrasing Dr. Warren Jackson, Director, University of Toronto Computing Services (UTCS) circa 1985)
You can delegate with zfs allow. Relevant permissions are send, receive, maybe create?