http://blog.delphix.com/matt/2015/03/25/resumable-zfs-sendre...
https://github.com/zfsonlinux/zfs/issues/3896
e: Ah, they run ZFS on FreeBSD, but I don't think FBSD has it yet either...
> And I'm also unsure whether it's even possible interrupt a transfer and resume it later, if the underlying data has changed
There is no "underlying data has changed" in a snapshot, it's a revision of the filesystem. As for interrupting and resuming later, Delphix apparently has contributed a resumable zfs send/receive to OpenZFS, though I don't know if it's available in yours or rsync.net's distribution: http://blog.delphix.com/matt/2015/03/25/resumable-zfs-sendre...
As for the concerns of sending small files first, I don't think ZFS could even use that: I don't believe it's content-addressed, so if you send a set of blocks from snapshot 1, interrupt and send snapshot 2 instead the blocks common to both will still be re-sent, ZFS only knows the block commonality from snapshots and since snapshot 1 hasn't been pushed its contents can't be used for snapshot 2. Unless the resumable replication support uses content addressing but that doesn't seem to be the case.
Because then you have to start form scratch every time. The snapshots are so large that if you wanted to send a complete one, a large amount of stuff will have changed.
My filesystems are pretty massive, but my internet connection is pretty crappy. I currently am running a script I hacked together which rsyncs my files up to rsync.net in (roughly) file size order - smallest first, largest last. This way, changes to huge files don't spend hours/days backing up, and preventing the backup of smaller files.
I haven't yet found a better way to do this.