search

digint / btrbk

Tool for creating snapshots and remote backups of btrfs subvolumes
https://digint.ch/btrbk/
GNU General Public License v3.0
1.67k stars 122 forks source link

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

Open ian-kelling opened 7 years ago

ian-kelling commented 7 years ago

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)

ceremcem commented 7 years ago

Hello,

  1. https://github.com/digint/btrbk/issues/137#issuecomment-294332331
  2. https://unix.stackexchange.com/questions/362395/any-chances-to-read-a-btrfs-snapshot-as-a-file

We are on this one :)

digint commented 7 years ago

I've been thinking of this myself, the problem is that it does not really fit into how btrbk works internally. Very basically spoken, btrbk compares UUID's on both sides and then takes action on it (for raw backups, the UUID's are "faked" on the filename). I fear that such a feature would mess up things, but I can't tell for sure before trying and thinking this through.

Regarding the speed, I can't tell, as it depends on various things (compression, encryption, SSH vs NFS protocols, buffers, ionice, ...), but I'd say this is really only a secondary issue. The main benefit would be to have robustness on flaky networks.

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.

In this case, btrbk would need to spawn a (detached) process for receiving, probably it would be more robust to have a separate job on the remote target which handles such things.

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.

Probably even 3x the disk space, as the send stream contains lots of metadata.

Proposed solution

For the temporary file, the "raw" feature could be enhanced to support resuming (not sure if it possible though, this requires btrfs send to create identical streams on each invocation, or we'll also need a temporary file on the source side).

Then, on the receiving side, some btrbk collect command could check all "raw" files from the first step, and receive them to real subvolumes.

ian-kelling commented 7 years ago

Proposed solution

Sounds ok to me.

ceremcem commented 7 years ago

If we decide to keep whole temporary file on the source, this means we can not ever use more than half of our disk size. You have 1 TB of disk? Then 500 GB is trashed. If you don't, you loose the ability of sending the first snapshot, where we need this feature most.