Support for Borg 2 borg transfer operation #879

New issue

Open

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

dhouck commented 2024-06-08 02:56:17 +00:00

Copy link

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.

witten commented 2024-06-08 07:09:51 +00:00

Owner

Copy link

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.

dhouck commented 2024-06-21 00:29:21 +00:00

Author

Copy link

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?

witten commented 2024-06-23 23:55:06 +00:00

Owner

Copy link

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

witten added the

waiting for response

label 2026-04-09 18:02:25 +00:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

parallel-borgmatic

command-hook-steps

2.1.7

2.1.6

2.1.5

2.1.4

2.1.3

2.1.2

2.1.1

2.1.0

2.0.13

2.0.12

2.0.11

2.0.10

2.0.9

2.0.8

2.0.7

2.0.6

2.0.5

2.0.4

2.0.3

2.0.2

2.0.1

2.0.0

1.9.14

1.9.13

1.9.12

1.9.11

1.9.10

1.9.9

1.9.8

1.9.7

1.9.6

1.9.5

1.9.4

1.9.3

1.9.2

1.9.1

1.9.0

1.8.14

1.8.13

1.8.12

1.8.11

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.15

1.7.14

1.7.13

1.7.12

1.7.11

1.7.10

1.7.9

1.7.8

1.7.7

1.7.6

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.7.dev0

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.26

1.3.25

1.3.24

1.3.23

1.3.22

1.3.21

1.3.20

1.3.19

1.3.18

1.3.17

1.3.16

1.3.15

1.3.14

1.3.13

1.3.12

1.3.11

1.3.10

1.3.9

1.3.8

1.3.7

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11

1.2.10

1.2.9

1.2.8

1.2.7

1.2.6

1.2.5

1.2.4

1.2.3

1.2.2

1.2.1

1.2.0

1.1.15

1.1.14

1.1.13

1.1.12

1.1.11

1.1.10

1.1.9

1.1.7

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

1.1.1

1.1.0

1.0.3

1.0.2

1.0.1

1.0.0

0.1.8

0.1.7

0.1.6

0.1.5

0.1.4

0.1.3

0.1.2

0.1.1

0.1.0

0.0.7

0.0.6

0.0.5

0.0.4

0.0.3

0.0.2

Labels

Clear labels   

blocked

  

breaking

  

bug

  

data loss

  

design finalized

  

good first issue

  

new feature area

  

question / support

  

security

  

waiting for response

No labels

blocked

breaking

bug

data loss

design finalized

good first issue

new feature area

question / support

security

waiting for response

Milestone

Clear milestone

No items

No milestone

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

borgmatic-collective/borgmatic#879

No description provided.