Support sending to a temporary file, then receive from that file.

Feature request.

I've found for a large initial btrfs send, it takes something like 30% as much time to send to a file on an nfs mount, then receive from that file on the remote system, vs using btrbk with it's standard send over ssh directly to receive. I don't have an exact number, it should be tested. I assume the speedup holds true for incremental snapshots too.

Using ssh to send to a file instead of nfs, I think that it would be still significantly faster, maybe 50-70% the normal time, I'm not sure, it needs to be tested. If it's the case that ssh is also faster, but not as fast, both methods should be supported but ssh implemented first, since it's probably simpler to implement and would be more widely used.

Note, until this is implemented, to speedup a long initial backup, you can manually run a btrfs send / receive, naming the backups as btrbk would and get the same result as running btrbk.

This would also make btrbk more resilient to failures. Half or so of the normal time (again, needs testing) is spent transferring to the temporary file, and then after that, only a local operation on the receiving host needs to complete. During this time, the network or the sending host could go down, and the backup could still complete. In the case of btrbk pulling a snapshot from a remote host, this should just work. In the case of btrbk sending to a remote host, some additional work would probably be needed to allow the receiving host to complete it's receive independently in the case of failure on the sending host. Perhaps a special exit code would be in order if the sending host lost network connectivity while waiting for the remote host to do it's local receive from the temporary file.

The downside of this feature of course is that you temporarily use twice the snapshot size in disk space on the receiving host, but it would still be worth it for many people.

For my main backup job, I have extra space on the backup host and I would keep this feature on all the time.

(edited wording)

No files, tests, or entry points are named. Start by tracing btrbk's existing remote btrfs send/receive path and its SSH handling, then measure the proposed temporary-file flow for initial and incremental snapshots; done means the flow is supported with clear behavior when transfer or remote receive fails.

Written by the indexing model from the issue text.