Support for Borg 2 borg transfer operation #879

Open
opened 2024-06-08 02:56:17 +00:00 by dhouck · 3 comments

What I'd like to do and why

(I understand that this will likely be low priority until Borg 2 comes out)

It would be nice to have support for the borg transfer command between related repositories, as an alternate method of backing up to multiple repositories. Instead of doing similar backups to multiple repositories, as is currently required, this could just do one backup, and transfer the archive between repositories.

Other notes / implementation ideas

This would help with consistently between archives (see eg. #846), as well as many other situations where borg transfer is useful.

### What I'd like to do and why (I understand that this will likely be low priority until Borg 2 comes out) It would be nice to have support for the `borg transfer` command between related repositories, as an alternate method of backing up to multiple repositories. Instead of doing similar backups to multiple repositories, as is currently required, this could just do one backup, and transfer the archive between repositories. ### Other notes / implementation ideas This would help with consistently between archives (see eg. #846), as well as many other situations where `borg transfer` is useful.
Owner

I might be missing something, but borgmatic transfer is already implemented (since borgmatic 1.7.0). Does it not work for the related repository use case?

... as an alternate method of backing up to multiple repositories.

Just be aware of the caveats here: https://borgbackup.readthedocs.io/en/stable/faq.html#can-i-copy-or-synchronize-my-repo-to-another-location ... A transfer might be slightly better than a bit-for-bit sync, but may share some of the downsides as well.

I might be missing something, but `borgmatic transfer` is already implemented (since borgmatic 1.7.0). Does it not work for the related repository use case? > ... as an alternate method of backing up to multiple repositories. Just be aware of the caveats here: https://borgbackup.readthedocs.io/en/stable/faq.html#can-i-copy-or-synchronize-my-repo-to-another-location ... A `transfer` might be slightly better than a bit-for-bit sync, but may share some of the downsides as well.
Author

I saw documentation for borgmatic transfer which seems similar to default borg transfer, but not for putting it in the config files to run automatically. Maybe I just missed something?

I saw documentation for `borgmatic transfer` which seems similar to default `borg transfer`, but not for putting it in the config files to run automatically. Maybe I just missed something?
Owner

Oh, no, you didn't miss anything. I misunderstood your use case! You want borgmatic to run the transfer as part of regular backups rather than the user running transfer manually as a one-off.

I think I agree that it sounds like something that could be useful. So I guess my question is how would this be configured? Maybe something like this?

repositories:
    - path: source.borg
      label: my-source-repo
    - path: target.borg
      label: my-target-repo
      source: my-source-repo

That would cause source.borg to get populated by a traditional borgmatic create, while target.borg would get populated by a transfer from source.borg. Presumably though it would only transfer the latest archive?

Oh, no, you didn't miss anything. I misunderstood your use case! You want borgmatic to run the `transfer` as part of regular backups rather than the user running `transfer` manually as a one-off. I think I agree that it sounds like something that could be useful. So I guess my question is how would this be configured? Maybe something like this? ```yaml repositories: - path: source.borg label: my-source-repo - path: target.borg label: my-target-repo source: my-source-repo ``` That would cause `source.borg` to get populated by a traditional borgmatic `create`, while `target.borg` would get populated by a `transfer` from `source.borg`. Presumably though it would only transfer the latest archive?
witten added the
new feature area
label 2024-06-23 23:55:46 +00:00
Sign in to join this conversation.
No Milestone
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#879
No description provided.