Filespooler makes an excellent tool for handling Backups. In fact, this was the case the prompted me to write it in the first place.
Using Asynchronous Communication for backups has a lot of advantages. It effectively trades latency for reliability; you have a lot of confidence that the backup will actually arrive. What you often don’t have is a guarantee that backups will arrive in order. This can be a problem when dealing with incremental backups, which must be applied in order on the destination, whether they’re from ZFS, tar, dar, and so forth.
The general idea would be to pipe a streaming output to fspl prepare -i - and send that to the remote, where fspl process would use zfs receive, tar -xf -, or whatever the appropriate command is to unpack and store the archive. Alternatively, perhaps the remote end will just store the file somewhere (though in that case, Filespooler is probably overkill).
Links to this note
Filespooler is a way to execute commands in strict order on a remote machine, and its communication method is by files. This is a perfect mix for Syncthing (and others, but this page is about Filespooler and Syncthing).
Filespooler lets you request the remote execution of programs, including stdin and environment. It can use tools such as S3, Dropbox, Syncthing, NNCP, ssh, UUCP, USB drives, CDs, etc. as transport; basically, a filesystem is the network for Filespooler. Filespooler is particularly suited to distributed and Asynchronous Communication.